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I.    Executive  Summary 


Information  Technology  as  a  Foundation  for  DoD  Improvement 

Almost  all  organizations  these  days  confront  increased  demands  for  efficiency  and 
responsiveness  to  the  markets  they  serve.  Managers  of  information  technology  find 
themselves  in  the  thick  of  the  fray,  because  most  of  their  organizations  are  looking  to 
information  technology  as  one  of  the  primary  means  of  coping  with  worldwide 
competition.  It  is  difficult  to  think  of  any  substantial  challenge  facing  these  organizations 
—  improved  service  or  product  quality,  reduced  cycle  times  for  all  their  business 
functions,  improved  coordination  across  far-flung  activities,  more  efficient  use  of 
resources  —  for  which  information  technology  does  not  contribute  something  to  the 
solution. 

With  the  largest  single  pool  of  information  technology  in  the  world,  the 
Department  of  Defense  (DoD)  is  by  no  means  immune  from  these  effects.  The  dramatic 
political  and  military  changes  that  have  occurred  in  the  world  over  the  past  couple  of 
years  call  for  corresponding  changes  in  the  way  DoD  does  business.  Leaders  within  and 
outside  of  DoD  are  challenging  each  activity  to  justify  its  contribution  to  national  defense 
and  to  reduce  its  costs  as  much  as  possible  consistent  with  its  essential  missions.  Like 
most  other  large  organizations,  DoD  is  looking  to  information  technology  as  a 
fundamental  building  block  of  any  long-term  improvement  program.  DoD's  Corporate 
Information  Management  (CIM)  initiative  constitutes  a  critical  component  of  any  such 
program. 


USACE  —  A  Leader  in  Applying  Information  Technology 

An  important  principle  of  the  CIM  initiative  is  to  identify  the  best  practices  within 
DoD  agencies  so  that  they  can  be  borrowed  and  emulated  throughout  the  Department. 
The  U.S.  Army  Corps  of  Engineers  (USACE)  provides  just  such  a  model-  its  business 
re-engineering  strategy.  It  has,  in  fact,  been  recognized  by  the  Director  of  Defense 
Information,  for  a  "golden  nugget"  award  that  signifies  leadership  in  applying 
information  technology.  USACE  demonstrates  how  an  agency  can  effect  major  changes 
through  the  intelligent  use  of  information  technology.  The  Corps  strategy  appears  to  be 
quite  capable  of  being  applied  in  other  organization  within  DoD,  the  Federal  government, 
and,  indeed,  the  private  sector. 

USACE  and  Business  Re-Engineering 

USACE  is  the  largest  engineering  organization  in  the  world,  with  an  annual 
budget  of  $9  billion.  It  supports  DoD  construction  activities,  handles  large  civil  works 
programs,  and  contracts  with  various  governmental  agencies  to  perform  a  wide  variety 
of  civil  engineering  works.  The  largest  single  source  of  funding  comes  from  the  outside 
contracts,  for  which  it  has  to  compete  with  private-sector  engineering  firms.  It  thus  has 
ample  incentive  to  strive  for  efficiency  and  effectiveness. 

Through  the  early  1980's,  USACE's  experience  with  computer-based  systems  was 
much  like  many  large  organizations.  A  large  variety  of  systems  were  developed  by 
subgroups  within  the  Corps.  This  was  done  with  little  or  no  high-level  support  or 
direction.  The  resulting  "stovepipe"  systems  may  have  met  the  needs  of  individual 
functional  groups,  but  there  existed  almost  no  integration  across  functions.  As  a  result, 
USACE  information  systems  suffered  from  a  great  deal  of  duplication  and 
inconsistencies,  and  failed  to  meet  the  overall  goals  of  the  organization. 

In  1982,  the  General  Accounting  Office  issued  a  critical  report  on  data  processing 
practices  within  USACE.  The  report  criticized,  among  other  things,  the  lack  of  central 
direction  for  Information  Systems  (IS)  activities,  the  absence  of  a  coherent  IS  plan  linked 


to  the  Corps'   missions,   the  unnecessary  duplication  of  functions  and  data,   and 
inconsistent  acquisition  policies  for  hardware  and  software. 

The  USACE  Action  Plan 

The  GAO  report  galvanized  USACE  into  action.  By  1984  an  Information 
Systems  Plan  was  issued.  It  proposed  the  appointment  of  the  Deputy  Commanding 
General  —  the  second  in  command  of  the  Corps  —  as  the  senior  IRM  official.  An 
Information  Resource  Management  Steering  Committee  was  established.  Composed  of 
12  high-level  functional  managers,  plus  non-voting  IS  managers,  the  Steering  Committee 
oversees  USACE  IS  policies.  A  subset  of  this  committee  forms  an  Executive  Committee, 
which  meets  weekly  to  provide  continuous  policy  direction.  Supporting  these  governance 
bodies  are  other  committees  that  deal  with  such  matters  as  defining  functional 
requirements  and  establishing  data  standards. 

Based  on  the  results  of  the  Information  Systems  Implementation  Plan  (ISPI) 
conducted  in  1985,  a  project  slate  of  proposed  candidates  for  re-engineering  were 
identified.  The  business  processes  were  to  be  modernized  and  applications  developed 
according  to  an  overall  plan  that  set  priorities  consistent  with  the  most  important 
management  needs  within  USACE.  A  communications  network  was  proposed  to  link  all 
USACE  locations.  Three  consolidated  regional  processing  centers  were  established  to 
serve  the  organization's  centralized  computing  needs.  Data  standards  were  set  to 
facilitate  data  sharing  and  reduce  data  redundancies  and  inconsistencies. 

The  Successful  Re-Engineering  Process 

USACE  has  developed  a  proven  methodology  for  successfully  modernizing 
information  systems.  The  success  results  from  the  synergy  of  pertinent  use  of  well 
proven  techniques  and  involvement  of  all-level  personnel  in  the  re-engineering  effort. 
Candidate  applications  for  re-engineering  are  identified  through  high-level  management 
committees.    Those  slated  for  development,  become  the  responsibility  of  a  relatively 


small  development  team  —  typically  six  to  eight  members  —  composed  of  a  mixture  of 

functional  and  technical  specialists.   The  team  follows  a  well-defined  process: 

Define  the  AS-IS  existing  system  to  provide  a  baseline  for  considering  a  new 
alternative. 

Examine  each  existing  activity  to  determine  whether  it  should  be  continued, 
eliminated,  or  revised. 

Design  alternative  TO-BE  systems. 

Build  a  business  case  —  a  cost-benefit  analysis  —  for  each  alternative  design  and 
select  the  most  cost  effective  one. 

Develop  a  transition  plan  to  implement  the  chosen  design. 

Develop  a  detailed  functional  design  for  the  application. 

Acquire  the  application  —  preferably  through  a  "commercial  off  the  shelf 
(COTS)  product  that  meets  US  ACE  needs. 

If  no  COTS   is  found,  install  a  pilot  implementation  through  an  iterative 
prototyping  process  that  involves  careful  testing  and  user  reviews. 

Install  the  application  where  appropriate,  based  on  a  Corps- wide  deployment  plan. 

Lessons  Learned 

US  ACE' s  experience  provides  some  valuable  guidelines  for  agencies  wishing  to 
pursue  a  successful  organization-wide  process  to  deploy  information  systems.  Each 
agency  has,  of  course,  its  own  unique  set  of  requirements  and  culture.  Nevertheless,  the 
general  process  used  by  US  ACE  should  find  widespread  applicability.  The  principal 
lessons  learned,  which  provide  valuable  guidelines  for  other  agencies  with  aspirations 
similar  to  USACE's,  are  as  follows: 

•  Top-management  support,  combined  with  support  at  all  levels  of  the  organization, 
is  essential  for  any  far-reaching  program  of  business  re-engineering. 

•  Business  re-engineering  should  precede  any  attempt  to  develop  new  information 
systems. 


A  Business  re-engineering  STRAP  is  needed  for  modernization  of  any  process. 

Heavy  user  participation  —  gained  through  committee  arrangements  and  other 
mechanisms  —  is  critical  at  all  levels  of  the  development  process. 

Top-level  functional  managers  are  needed  to  serve  as  "executive  champions"  of 
an  application. 

A  well-structured  methodology  is  needed  to  provide  the  discipline  and  guidance 
for  the  re-engineering  process. 

A  supportive  infrastructure  —  effective  communications  networks  and  data 
sharing  mechanisms  —  is  an  essential  ingredient  to  a  successful  IS  program. 

A  strong  organizational  commitment  to  sharing  the  corporate  data  assets  is 
imperative. 


II.    Foundations  for  Business  Re-Engineering  in  DoD 


This  section  serves  as  a  brief  introduction  to  the  basic  concepts  and  history  that 
could  be  considered  as  foundations  of  a  sound  business  re-engineering  process.  These 
include:  Corporate  Information  Management  (CIM),  Total  Quality  Management  (TQM), 
Activity-Based  Costing  (ABC),  and  Management  of  Planned  Change.  The  reader  who 
is  familiar  with  these  concepts  may  wish  to  skip  this  section. 

A.      Towards  a  Cost-Effective  DoD  Organization 

Facing  deep  cuts  in  government  defense  spending,  military  leaders  in  all  areas 
will  be  challenged  to  accomplish  their  mission  with  a  severely  limited  budget.  The  costs 
of  the  current  military  establishment  must  be  reduced  and  effectiveness  increased  if  the 
scaled-down  military  of  the  future  is  to  be  fully  capable  of  responding  to  challenges 
throughout  the  world.  Military  leaders  will  be  forced  not  only  to  eliminate  waste,  but 
also  to  make  improvements  in  quality  and  efficiency.  Such  an  effort  calls  for  a 
continuously  orchestrated  improvement  process  involving  all  activities  of  the 
organization. 

Modern  management  concepts,  including  CIM,  TQM,  ABC,  and  Business  Re- 
Engineering,  are  widely  recognized  as  critical  baseline  principles  for  a  modernization 
program.  It  is  important  that  DoD  program  managers  understand  the  essence  of  these 
concepts  to  successfully  harness  the  synergy  of  management,  re-engineering,  and 
prototype  application  for  a  more  cost-effective  DoD  organization  (Figure  1). 

1.        The  Corporate  Information  Management  Initiative 

The  CIM  initiative,  introduced  within  the  Department  of  Defense  (DoD)  in 
October  1989,  has  been  heralded  as  an  initiative  to  improve  standardization,  quality,  and 
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Figure  1  -  Basic  Building  Blocks  for  Business  Re-engineering 


consistency  of  data  from  DoD's  multiple  information  systems.1  The  program  is 
designed  to  eliminate  redundant  information  systems  and  software  from  distributed 
administrative  areas.  Common  applications  are  consolidated  into  information  resource 
centers  that  operate  under  standardized  data  usage. 

Early  in  the  CIM  process,  DoD  formed  an  Executive  Level  Group  (ELG), 
comprised  of  information  system  specialists  from  the  private  sector,  to  formulate  a  DoD- 
wide  strategy  for  downsizing  the  information  resource  management  structure  in  response 
to  the  shrinking  defense  budget.  The  unique  aspect  of  CIM  has  been  its  move  away  from 


'GAO/IMTEC  91-17BR  "Potential  Reductions  to  Defense's  ADP  Budget  Request" 
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the  concept  of  management  of  information  systems  to  one  of  management  of  information 
as  a  valuable  resource.2 


Principle  1 :  Customer  Satisfaction 

•  Your  Customer  —  the  function  with  business  process 
authority  and  performance  accountability  —  defines  systems 
requirements,  manages  implementation  and  measures  results. 

•  An  information  resource  organization  becomes  a  fee  for 
service  technology  service  center. 

Principle  2:  Simplification  of  Processes  Before  Computerization 

•  The  business  process  must  be  simplified  before  it  is 
computerized. 

•  Apply  technology  only  after  you  are  sure  the  organization  can 
manage  the  proposed  change. 

•  Increase  effectiveness  and  reduce  cost  of  the  process  by 
changing  how  people  work. 

Principle  3:  Implementation  of  Systems  Through  Prototyping 

•  The  fastest  process,  at  the  lowest  risk,  is  through 
evolutionary  improvement  of  the  process. 

•  The  best  learning  environment  is  achieved  through  frequent 
success. 


Table  1 .  CIM  Principles 


2Logistic  Systems  Architects  (LSA)  White  Paper  on  CIM,  USACE. 
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CIM  is  founded  on  three  basic  principles:  customer  satisfaction,  simplification 
of  processes  before  computerization,  and  implementation  of  systems  through  prototyping 
(Table  1).  Implementation  of  these  principles  should  result  in  achieving  the  quality 
value-added  continuum  shown  earlier  in  Figure  1. 

The  ELG  strategy  for  information  management  emphasizes  a  centralized  program 
for  data  standards  and  process  modeling.  Data  standardization  facilitates  data  sharing  and 
provides  a  clearer  view  of  how  information  is  used  within  a  process.  Standardizing  a 
data  element  implies  that  information  must  be  handled  efficiently  at  a  low  cost  in  order 
to  preserve  its  added  value  to  the  organization.  Through  its  guidelines,  the  CIM 
initiative  insists  that  information  must  be  used  to  simplify  the  way  DoD  does  business. 

The  business  process  must  be  simplified  before  it  is  computerized.   According  to 

CIM  guidelines,  an  organization  should: 

Seek  a  non-computer  solution  through  process  simplification  and  elimination  of 
non-value  added  steps 

Re-engineer  existing  systems 

Use  proven  system  applications 

Use  'off-the-shelf  software  and  systems 

Develop  systems  that  have  joint-service  applicability 

Use  service-unique  systems  only  if  the  above  guidelines  will  not  meet  the 
requirements. 

The  key  objectives  are  to  identify  and  establish  information  requirements,  data 
definitions,  and  formats  that  allow  standardization  of  automated  data  processing  (ADP) 
systems  throughout  DoD. 

Ideally,  once  data  standardization  is  achieved,  ADP  systems  that  perform  similar 
functions  can  be  integrated  into  systems  that  share  resources.  The  following  eight 
functional  areas  have  been  identified  as  candidates  for  integrated  information  management 
and  cost  savings: 

•  Civilian  payroll 

•  Civilian  personnel 
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Contract  payment 

Financial  operation 

Government  furnished  material 

Medical  services 

Warehousing,  shipping,  and  distribution  centers. 

Other  areas  within  DoD  (e.g.,  Command  and  Control)  that  might  serve  as  candidates  for 
the  CIM  initiative  are  being  evaluated. 

The  Department  of  Defense  has  an  annual  budget  of  over  $9  billion  to  acquire, 
maintain,  and  operate  general-purpose  ADP  systems.  It  is  estimated  that  $4  billion  of 
this  amount  is  spent  to  develop  new  computer-based  applications  and  upgrade  existing 
systems.  An  effective  use  of  information  technology  (e.g.,  business  re-engineering, 
structured  analysis  and  design  tools,  application  generators,  etc.)  is  expected  to  save 
approximately  25  percent  of  the  system  development  and  procurement  costs.3  Additional 
savings  can  be  realized  in  the  future  through  the  operation  and  maintenance  of  fewer, 
more  integrated  systems. 

In  anticipation  of  a  potential  $1  billion  savings  in  information  systems 
development  and  acquisition  costs  through  CIM,  the  Office  of  the  Secretary  of  Defense 
(OSD)  has  begun  a  five-year  phased  reduction  of  ADP  budgets  for  all  member  services. 
The  plan  calls  for  a  $100  million  reduction  in  fiscal  year  1991,  $200  in  1992,  and  $300 
million  in  years  1993  through  1995. 


2.        Value- Adding  Strategies  for  Information  Systems 

The  ELG  has  identified  the  following  value-adding  strategies  for  information 
systems: 

•  Use  re-engineering  methodologies  (e.g.,  process  and  data  models)  to  determine 

joint  use  application. 


3GAO/IMTEC  91-17BR 
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Employ  tools  to  measure  effectiveness  and  efficiency  that  compare  public  and 
private  sector  business  processes  and  determine  future  direction  for  information 
systems. 

Establish  a  fee  for  information  service  as  a  way  of  determining  system  efficiency. 

Promote  the  development  of  information  systems  with  open  system  architecture 
to  free  DoD  from  proprietary  constraints  on  hardware  and  software. 

Enforce  data  standards  to  achieve  full  conformity  with  Federal  Information 
Processing  Standards  and  the  Commerce  Department's  National  Institute  for 
Standards  and  Technology  (NIST). 

Manage  information  resources  to  allow  rapid  deployment  of  new  technology. 

Educate  all  establishments  within  DoD  on  CIM  goals  and  objectives. 


B.      A  Framework  for  Business  Re-Engineering 

1.        Total  Quality  Management  (TQM)  in  DoD 

Total  Quality  Management  /  Leadership  (TQM/TQL)  rests  heavily  on  the 
teachings  of  W.  Edward  Deming.  Deming's  approach  to  quality  control  is  more  than  a 
scientific  method  to  improve  a  worker's  speed  of  productivity.4  In  recognition  that 
quality  has  become  a  key  competitive  factor,  organizations  must  be  responsive  to 
customer  needs,  concentrate  on  improvement  of  process  as  the  never-ending  business  of 
the  enterprise,  and  promote  teamwork  among  those  who  carry  out  the  business 
operations.  The  relationship  between  improved  quality  and  overall  business-success  in 
an  organization  is  shown  in  Figure  2. 

As  tangible  ways  to  improve  and  measure  quality,  statistical  indicators  (e.g., 
trend  and  variance  analysis)  provide  feedback  that  show  the  effects  of  change.  TQM 
utilizes  seven  graphic  tools  for  measuring  and  explaining  process  quality  improvement 
(Table  2).   The  benefits  derived  from  these  graphics  tools  fit  well  with  the  four  phases 


4Deming  defines  quality  management  as  " . .  .understanding  the  customer's  needs  and  providing 
a  product  that  meets  his  satisfaction."   The  "best  return"  on  each  dollar  spent  is  the  goal. 
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Figure  2.    Quality  Contributions  to  Business  Improvement 


(Add-Plan-Do-Check)  of  the  Deming  quality  improvement  cycle  (Figure  3).  The  cycle 
ideally  should  remain  in  an  endless  loop,  ever  monitoring  and  improving  the  quality  of 
the  process. 

It  is  important  to  note  that  quality  control  measurements  are  meant  to  be  a  tool 
for  change.  Unexpected  problems  could  arise  if  management  by  numbers  became  the 
only  motivation  for  applying  statistical  quality  control. 

DoD  seeks  to  spread  TQM  concepts  to  the  field  with  leadership  geared  to  change 
(TQL).  Management  leadership  is  critical  to  bringing  about  necessary  cultural  changes 
and  improve  quality  within  DoD  organizations.  To  achieve  this  goal,  upper  DoD 
management  has  formed  an  Executive  Steering  Group  (ESG)  whose  mission  is  to  develop 
the  strategic  goals  of  TQM  for  the  organization. 
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FLOW  CHART 

Promotes  understanding  between  value 
and  cost  added  steps. 

CAUSE  &  EFFECT 
DIAGRAM 

Relates  positive  and  negative  effects  that 
cause  variance  in  quality. 

PARETO  CHART 

Bar  graph  to  simplify  large  data  tables 
providing  basis  for  identifying  problem 
areas. 

HISTOGRAM 

Bar  graph  represents  the  amount  of 
variance  between  results  and 
specifications. 

SCATTER  DIAGRAM 

Indicates  how  changes  in  one  variable  are 
related  to  changes  in  another  variable. 

RUN  CHART 

Identifies  patterns  of  performance  for 
changes  in  progress. 

CONTROL  CHART 

Reveals  cause  and  statistical  control  of 
variations  from  standards,  along  with 
process  capability. 

Table  2.  Graphic  Tools  for  Measuring  Quality  Process  Improvement 


2.        Activity  Based  Costing 

The  CIM  initiative  stresses  cost  containment  and  the  elimination  of  activities  that 
do  not  add  value  to  the  business  process.  Activity  Based  Costing  (ABC)  holds  promise 
as  being  an  invaluable  tool  in  evaluating  and  containing  costs. 
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Figure  3.  Graphic  Tools  Associated  with  the  Quality  Improvement  Cycle 


a.         The  Illusion  of  Cost  Savings 

Supporters  of  ABC  management  aggressively  argue  that  traditional  methods  of 
cost  accounting  dwell  too  much  on  past  accounting  data  in  trying  to  make  future 
improvements.  ABC  as  a  managerial  approach  is  in  stark  contrast  to  traditional  cost 
accounting  methods  that  see  cost  only  as  a  function  of  output  volume.  Traditional  cost 
accounting  techniques  examine  where  monetary  resources  are  expended.  Management 
may  use  such  information  to  determine  where  budgets  can  be  trimmed  to  reduce  overall 
expenditures  within  the  company.  Budgetary  reductions  often  focus  on  downsizing  the 
work  force,  pay  cuts,  forced  early-retirement,  or  elimination  of  research  and  development 
efforts.  The  loss  of  a  skilled  work  force,  combined  with  reduced  product  research  and 
development  effort,  invariably  leads  to  a  reduction  in  product  quality.  Cost  cutting 
measures,  in  reality,  often  present  only  a  "surface  patch"  to  a  deeper  budgetary  problem. 
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The  illusion  of  reduction  in  operating  expense  exists,  but  organizational 
performance  decreases  due  to  inferior  quality  standards.  There  is  only  further  temptation 
to  increase  the  cost  cutting  measures  to  give  the  Profit  &  Loss  statement  another  short- 
term  gain.  Meanwhile,  quality  issues  remain  unaddressed.  Improving  the  appearance 
of  the  income  statement  often  does  nothing  for  an  organization's  attempts  at  maintaining 
its  objectives.  What  is  needed  is  a  cost  management  methodology  that  examines  not  only 
where  cost  are  incurred,  but  also  how  they  are  incurred. 

b.         Value-Added  Awareness 

Consistent  use  of  ABC  management  provides  a  measured  approach  to  cost 
reduction.  The  overall  cost  often  depends  on  decisions  made  across  department 
boundaries.  Across-the-board  cost  cuts  do  not  adequately  address  the  interrelation  of  the 
costing  decisions.  The  focus  should  be  on  the  elimination  of  those  costly  activities  that 
do  not  add  value,  rather  than  making  indiscriminate  cuts.5 


5An  example  of  the  value-added  awareness  in  die  production  process  using  activity  based 
costing  is  provided  by  the  Tektronix  Company's  Portable  Division,  a  manufacturer  of  portable 
electric  measuring  devices  (Shank,  p. 47).  In  the  face  of  increased  competition  for  market-share, 
the  organization  formulated  plans  to  change  the  way  it  made  its  products.  Tektronix  found  that 
traditional  cost  accounting  techniques  were  "obsolete  and  restrictive."  They  were  scrapped  in 
favor  of  a  cost  management  system  that  Tektronix  called  "accounting  for  continuous 
improvement. " 

The  result  was  an  evolutionary  overhaul  of  the  previous  cost  accounting  system  that  led 
to  the  elimination  of  the  following  activities: 

The  production  work  order  system 

Standard  product  cost  calculations 

Cost  variance  reporting 

Flexible  budgets  procedures  for  cost  control 

The  scrap  and  rework  reporting  system 

Monthly  inventory  tracking  &  reporting 

Accumulation  of  work  in  process  (WIP)  inventory  cost 

Monthly  summaries  reports  of  financial  performance. 
These  activities  added  no  increased  value  to  the  finished  product.  They  involved 
redundancies  in  accounting  for  materials  used,  logging  waste  that  should  not  occur  in  the  first 
place,  inspecting  inefficient  procedures  instead  of  correcting  them,  and  producing  intermediate 
status  reports.  Many  of  these  activities  were  replaced  with  more  modern  reporting  procedures 
that  provide  management  real  time  cost  analysis  information  that  allows  an  organization  to  make 
realistic  decisions  on  production  cost. 
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Figure  4.  Analysis  of  Business  Activities  Based  on  ABC 

Effective  cost  management  needs  to  look  not  only  at  the  cumulative  monetary 
amount  spent  on  the  product  manufactured,  but  also  at  the  cost  of  the  individual 
processes,  or  activities,  in  the  production  operation  (Figure  4).  This  allows  management 
to  isolate  activities  within  the  production  process  and  evaluate  whether  certain  activities 
are  cost-efficient  and  add  sufficient  value  to  the  product. 

Activity-Based  Cost  Management  fosters  evolutionary  change  to  occur  in  the 
production  process.  As  cost  drivers,  activities  that  are  obsolete  must  be  eliminated  from 
the  process  and,  if  necessary,  replaced  by  alternative  procedures.  The  organization  can 
continuously  modify  activities  as  part  of  its  cost  driver  monitoring  effort. 
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3 .  Management  of  Planned  Change 

Affecting  change  within  a  large-scale  corporate  structure  is  a  complex  and 
traumatic  process  that  involves  risk,  uncertainty,  and  resistance.  However,  change  is 
necessary  if  an  organization  wishes  to  remain  competitive.  For  a  planned  change  to  be 
effective,  a  large-scale  organization  such  as  DoD  must  take  into  consideration  its  size  and 
cultural  history,  depth  of  change  in  the  organizational  hierarchy,  and  whether  the  change 
crosses  functional  areas. 

Areas  where  change  offers  substantial  opportunities  for  improvement  include: 

Better  relationship  between   the  organizational  culture  and   the  competitive 
environment 

Refinement  of  the  input-output  transformation  process 

Improvement  of  product  quality 

Differentiation,  coordination,  and  integration  of  effort  across  functions 

Human  resource  management 

With  the  key  areas  of  change  identified,  management  must  realize  that  designing 
and  implementing  a  planned  change  involve  re-formulating  corporate  strategies  and 
structures,  incorporating  new  technology  (including  the  use  of  information  technology), 
and  re-evaluating  employee  development  programs.  Procedures  to  promote  information 
exchange,  enhance  decision  making  and  conflict  resolution,  and  encourage  participation 
and  cooperation  between  functional  areas  should  be  carefully  designed  and  implemented 
during  the  change  process. 

4.  Business  Re-Engineering 

The  history  of  business  re-engineering  began  in  the  early  1980' s  in  the 
manufacturing  sector.  Concepts  such  as  Just-in-Time  (JIT)  inventory  and  concurrent 
engineering  were  developed  and  often  supported  by  sophisticated  computer  systems. 
Organizations  were  forced  to  carry  out  new  business  methods,  rethinking  the  way  they 
operated. 
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Business  re-engineering  is  based  on  the  concept  that  organizations  must  change 
the  way  they  work  in  order  to  effect  a  major  improvement.  By  breaking  down  operations 
into  manageable  and  discrete  processes,  the  organization  can  identify  activity  areas  for 
elimination  or  improvement.  From  this  point  of  view,  re-engineering  is  a  logical 
outcome  of  ABC,  TQM,  and  management  of  planned  change. 

Re-engineering  involves  three  steps: 

•  Examination  of  the  business  process 

•  Optimizing  the  process  for  efficiency 

•  Implementing  a  new  business  system  (applying  information  technology  when 
appropriate  to  the  new  process). 

An  effective  way  to  carry  out  a  program  of  re-engineering  is  to  assemble  a  team 
that  is  composed  of  members  representing  a  broad  range  of  functional  areas  within  an 
organization.  The  team  should  analyze  existing  business  processes  and  activities  in  an 
attempt  to  fully  understand  the  current  operations. 

Once  the  current  business  activities  are  fully  understood,  the  re-engineering  team 
begins  to  optimize  them  for  efficiency  and  effectiveness.  Graphical  and  statistical  tools 
(such  as  those  used  in  TQM),  ABC  ,  and  common  sense  are  applied  to  assess  whether 
an  activity  adds  sufficient  value  to  justify  its  continuation.  The  basis  for  establishing  a 
new  business  process  is  to  enhance  the  value-added  activities  and  eliminate  the  remaining 
ones.  This  approach  systematically  creates  new  rules,  and  a  need  for  modernization. 
Table  3  lists  a  set  of  guiding  principles  for  re-engineering.6 


5.        Re-engineering  —  Go  Versus  No-Go 

The  decision  whether  to  revamp  a  business  process  or  to  "leave  it  as  is"  can  be 
very  traumatic  for  most  organizations.  Talk  of  any  change  is  often  a  source  of 
contention  as  to  the  best  path  for  process  improvement.  Knowing  when  to  re-engineer 
a  business  process  is  perhaps  more  crucial  than  the  mechanics  of  knowing  how  to  do  it. 


6  Hammer,  pp  108-110. 
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Thinking  that  re-engineering  is  a  panacea  for  any  business  process  is  a  trap  that  must  be 
avoided.  For  this  reason,  the  decision  to  re-engineer  an  existing  process  must  not  be 
made  lightly. 

The  following  provides  some  guidance  as  to  whether  or  not  an  organization  should 
re-engineer:7 

•  The  support  of  top  management  must  be  the  first  factor  affecting  whether  or  not 
an  organization  should  engage  in  a  re-engineering  program;  without  such  support, 
any  fundamental  change  is  almost  impossible. 

•  Processes  that  are  critical,  or  of  the  greatest  value,  to  the  organization's  mission 
should  take  precedence  over  the  ones  that  are  perceived  as  having  less  strategic 
impact. 

•  It  is  usually  not  cost  effective  to  re-engineer  a  process  that  will  soon  be  phased 
out.  Expected  benefits  of  a  re-engineered  process  may  not  be  able  to  offset  the 
conversion  costs. 

•  The  greater  the  complexity  of  a  process,  the  more  attractive  it  becomes  as  a 
candidate  for  re-engineering.  The  complexity  of  a  process  may  stem  from  its 
intrinsic  nature  —  e.g.,  the  process  may  involve  a  large  number  of  variables  and 
complicated  or  probabilistic  relationships  among  the  variables.  Re-engineering 
may  often  exploit  information  technology  to  deal  internally  with  the  complexity, 
thereby  reducing  the  apparent  complexity  as  seen  by  the  user  —  "so  complex,  it's 
easy,"  as  proclaimed  by  the  ad  for  the  automated  camera. 

•  An  old  process  that  has  undergone  continual  changes  and  accretions  often  presents 
an  excellent  opportunity  for  re-engineering.  An  activity  that  may  have  started  out 
as  a  clean  and  simple  process  gradually  becomes  more  and  more  convoluted  with 
appendages  to  handle  "special  cases"  and  "extensions."  Re-engineering  can  often 
sweep  away  this  accumulated  complexity  by  simplifying  the  process  and 
eliminating  unnecessary  functions. 

•  Although  complexity  is  a  difficult  phenomenon  to  measure,  experience  has  shown 
that  the  more  individuals  involved  in  a  process  the  more  complex  that  process  is; 
therefore,  there  is  a  greater  possibility  that  this  process  contains  non-value  adding 
steps. 


7Sittenauer  and  Olsem  of  the  USAF  Software  Technology  Support  Center  have  constructed 
a  self-assessment  survey  to  aid  in  the  decision  when  to  conduct  a  software  re-engineering  effort 
("Time  to  Re-engineer? ".Cross  Talk.  March  1992,  p. 21). 

20 


Re-engineering  is  most  successful  when  applied  to  one  process  at  a  time. 
Attempts  to  change  all  facets  of  the  business  process  at  once  must  be  avoided. 

The  selected  candidate  process  for  improvement  will  be  most  successful  if  the 
organization  can  nurture  a  consensual  decision-making  environment.  This  allows 
shareholder  commitment  to  the  re-engineering  effort. 


WHO  SHOULD  RE-ENGINEER? 

•  Non  manufacturing  firms  and  high  technology  firms  facing  tough 
competition 

•  Companies  in  need  of  a  radical  product  breakthrough 

•  Companies  under  fire  from  heavy  end-user  demands 

•  Companies  facing  financial  crisis 

PRINCIPLES  OF  RE-ENGINEERING 

Organize  around  outcomes,  not  tasks 

Have  those  who  use  the  output  of  the  process  perform  the  process 

Subsume  information  processing  work  into  the  real  work  that 
produces  the  information 

Treat  geographically  dispersed  resources  as  if  the  were  centralized 

Link  parallel  activities  instead  of  integrating  their  results 

Put  the  decision  point  where  the  work  is  performed,  and  build 
control  into  the  process 

Capture  information  once  and  at  the  source 


Table  3.  Guiding  Principles  for  Re-Engineering 
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In  summary,  DoD  has  recognized  business  re-engineering  as  a  means  for 
streamlining  business  operations.  DoD  agencies  must  not  simply  automate  existing 
inefficient  business  processes;  they  must  completely  change  the  way  they  operate. 
Information  technology  is  generally  an  important  vehicle  to  implement  change.  The 
Corporate  Information  Management  Program  reflects  this  approach.8 


""The  focus  of  CIM  is  on  management  methods  and  its  primary  objective  is  business  process 
improvement."  -  White  Paper  on  CIM,  Federal  Computer  Week,  September,  1991. 
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III.    US  ACE:    Re-Engineer  or  Perish 


A.      USACE  and  DoD  Business  Re-Engineering 

The  Army  Corps  of  Engineers  is  the  largest  engineering  organization  in  the 
world,  employing  approximately  43,000  civilians  and  900  military  personnel  worldwide. 
It  has  a  history  that  spans  over  two  hundred  years.  Its  military  districts  are  depicted  in 
Figure  5. 

The  USACE  mission  embraces  three  major  arenas:  military  construction,  civil 
works,  and  engineering  and  project  management  support  to  agencies  within  the  federal 
government  and  governments  of  other  nations.9 

Among  other  things,  USACE  is  responsible  for  construction  on  both  Army  and 
Air  Force  bases.  It  is  currently  undertaking  projects  that  coincide  with  the 
implementation  of  the  Base  Realignment  and  Closure  Act  of  1988.  In  1990,  USACE 
spent  $50  million  on  these  activities  and  estimates  that  it  spent  the  same  in  1991. 
USACE  is  also  responsible  for  providing  new  facilities  at  the  installations  that  will  be 
gaining  forces  as  a  result  of  this  Act. 

USACE  also  participates  in  a  large  civil  works  program.  This  includes  water 
resource  management  and  emergency  response.  As  part  of  water  resource  management, 
USACE  maintains  25,000  miles  of  inland  waterways  and  approximately  100  major 
seaports,  as  well  as  smaller  harbors.  These  waterways  are  critical  to  the  movement  of 


*The  general  mission  of  the  Corps  is  "To  manage  and  execute  engineering,  environmental, 
real  estate,  research  and  development,  and  readiness  programs  to  support  the  Army,  Department 
of  Defense,  and  the  Nation  during  peace  and  war.  Inherent  in  this  mission  is  providing  caring 
leadership  and  quality  products  and  services  consistent  with  environmental  values  and  the  highest 
standards  of  professional  integrity  and  excellence." 
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Figure  5.  US  ACE  Military  Districts  and  Regional  Processing  Centers  (Note  -  Civil 
Works  Boundaries  are  not  Depicted) 


commercial  and  military  traffic.  USACE  constructs  and  maintains  locks  and  dams,  as 
well  as  dredges  navigable  waterways.  Its  Emergency  Response  Teams  assist  in  areas 
stricken  by  flood,  drought,  tornadoes,  volcanic  eruptions,  or  similar  natural  disasters. 
They  conduct  rescue  operations,  restore  vital  transportation  links,  and  restore  essential 
resources  (such  as  drinking  water)  to  areas  suffering  such  disasters. 

Projects  for  federal  agencies  include  construction  of  space  shuttle  launch  and 
landing  facilities  for  NASA,  bulk  mail  facilities  for  the  U.S.  Postal  Service,  transmitters 
for  Voice  of  America,  and  facilities  for  the  Department  of  Energy.  Projects  for 
governments  of  other  nations  vary.  Most  recently,  USACE  was  involved  in  the  Kuwait 
recovery  program  following  Operation  Desert  Storm. 
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The  current  USACE  total  annual  budget  is  $9  billion.  In  1990,  $354  million  was 
spent  on  information  technology,  and  $7  million  was  spent  on  the  Information  Systems 
Modernization  Program.10  Budgetary  support  for  USACE  missions  comes  from  three 
distinct  sources.  Operations  and  Maintenance  (O&M)  funding  provides  direct 
appropriations  for  military  operations.  Civil  funds  finance  the  civil  works  mission  of 
USACE.  The  third  and  most  significant  source  of  funding  is  the  money  received  through 
reimbursable  programs.  These  funds  are  received  through  the  awarding  of  contracts  to 
USACE  by  agencies  within  the  federal  government  and  the  governments  of  other  nations. 
To  win  reimbursable  projects,  USACE  competes  with  private  sector  construction  firms 
and  must  sell  its  services  to  federal  agencies. 

An  adverse  GAO  audit  in  1982  forced  USACE  to  change  the  way  it  managed 
information  systems.  USACE  commenced  a  massive  information  systems  improvement 
plan  encompassing  all  areas  of  information  management.  Beginning  in  1983,  a 
comprehensive  program  was  devised  for  modernizing  hardware,  software,  and  the 
acquisition  and  management  of  information  systems. 

With  business  re-engineering  as  an  essential  facet  of  this  modernization  effort, 
USACE  wants  to  be  a  pioneer  that  serves  as  an  excellent  model  for  CIM.11  In  April 
1991,  USACE  proposed  the  following  nine  information  systems  as  interim  candidates  for 
potential  DoD-wide  application: 

•  Computer  Aided  Cost  Estimating  System 


"interview  with  Mr.  Dave  Spivey,  Information  Modernization  Program  Manager,  Dec  18, 
1991. 

11  "As  the  CIM  model  agency,  The  Corps  would  establish  a  program  to  assist  DoD 
organizations  and  agencies  in  transitioning  to  CIM  from  a  functional  point  of  view.  Our 
experiences  and  lessons  learned  in  executing  a  CIM  like  philosophy  over  the  years  places  us  in 
a  unique  position  to  assist  other  organizations  with  their  modernization  efforts.  We  already  have 
in  place  many  of  the  supporting  mechanisms  needed  to  support  others,  and  we  have  often  been 
called  upon  to  assist  Army,  DoD,  and  other  government  organizations  with  technical  support  and 
advice  concerning  their  information  programs.  To  our  knowledge,  we  are  the  only  organization 
in  DoD  to  have  undertaken  this  type  of  program  on  an  agency-wide  basis."  Memorandum  from 
USACE  to  Director  of  Information  Systems  for  Command  Control  and  Computers  dated  15  April 
1991,  proposing  USACE  as  CIM  model  agency. 
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Automated  Review  Management  Systems  (ARMS) 

Computer  Aided  Design  and  Drafting  (CADD) 

Architect  Engineering  Contract  Administration  Support  System  (ACASS) 

PC  Economics  Package  (ECONPAC) 

Real  Estate  Management  Information  System  (REMIS) 

Integrated  Facilities  System  -  Micro  (IFS-M) 

Construction  Contractor  Appraisal  System  Support  (CASS) 

Corps  of  Engineers  Automated  Legal  System  (CEALS) 

These  candidates  meet  CIM  system  principles  and  have  been  approved  for  use  throughout 
US  ACE.12 

Based  on  proven  systems  development  techniques,  USACE  has  developed  a 
structured  approach  to  business  re-engineering.  The  business  re-engineering  methodology 
is  a  generalized  and  repeatable  process  that  can  be  taught  and  implemented  effectively.13 

By  adopting  an  adaptive  and  participatory  approach  to  implementation,  USACE 
has  enjoyed  some  early  success  in  dealing  with  the  issue  of  training,  corporate  change, 
and  all  of  the  challenges  associated  with  the  introduction  of  new  business  practices  in  the 
work  place.  The  lessons  learned  will  benefit  all  organizations  desiring  to  utilize  the 
USACE  business  re-engineering  methodology. 


12A11  systems  developed  under  CIM  are  characterized  by  the  following  principles: 
Vendor  independent 
Assembled  from  standard  components 
Interoperable 
Single  point  data  entry 
Non-redundant  databases* 
Developed  using  a  Life  Cycle  Management  Philosophy 

*  In  some  instances  me  USACE  modernization  program  incorporates  planned  redundancy. 

13This  methodology  has  been  described  as  a  "gold  nugget"  by  Paul  Strassmann,  Director  of 
Defense  Information,  who  stated,  "We  will  export  die  Corps  of  Engineers  Methodology 
throughout  the  Defense  Department."  -  White  Paper  on  CIM,  Federal  Computer  Week 
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B.       Organizational  Culture  and  Management  Philosophy 

The  Army  Corps  of  Engineers  organizational  culture  is  comparable  to  that  of  a 
large  and  successful  private  sector  corporation.  US  ACE  has  evolved  over  its  long 
history  into  an  elite  organization  with  a  "can-do"  attitude  towards  any  and  all  missions 
assigned,  striving  to  be  the  best  and  a  leader  within  DoD. 

Top  management  philosophy  within  USACE  is  strategic  and  visionary  in  nature. 
Senior  USACE  officials  have  identified  "corporate  effectiveness"  as  the  most  strategic 
issue  effecting  USACE  today.14  The  increased  effectiveness  of  operations  is  essential 
in  an  era  of  decreased  government  spending.  The  major  elements  of  corporate 
effectiveness  for  USACE  are: 

Human  Resources 

Leadership 

Performance  Accountability 

Corporate  Reorganization  and  Project  Management 

Innovation 

Management  of  Information. 

In  order  to  exploit  fully  the  power  of  available  technology,  USACE  recognizes 
that  it  must  continue  to  make  fundamental  changes  in  the  way  USACE  and  DoD 
approach  work.  In  the  past,  information  systems  were  developed  to  serve  separate 
functional  areas,  with  each  area  building  its  own  vertical  ("stovepipe")  systems  that  use 
their  own  data  and  imposed  almost  impenetrable  barriers  to  sharing  across  systems. 
Information  is  now  recognized  as  a  common  resource  that  must  be  used  to  streamline 
operations  and  change  the  way  business  is  conducted.  Although  information  technology 
does  not  drive  change,  it  enables  USACE  management  to  communicate  knowledge  and 
integration  of  data  in  new  ways.  The  ability  to  access  correct  information  at  the  right 
time  is  crucial  as  both  USACE  and  DoD  become  more  cost  sensitive.     Its  new 


"Modernization  Plan 
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technology    and       development    methodology    enables    USACE    to    move    toward 
comprehensive  systems  that  allow  information  sharing  throughout  the  entire  organization. 


C.      Historical  Overview  of  Information  Systems  prior  to 
Modernization  Efforts 

Prior  to  the  modernization  effort,  USACE  information  systems  consisted  of 
approximately  300  computer-based  systems  to  support  administrative  functions  and  over 
10,000  applications  to  aid  scientists  and  engineers  in  structural  and  architectural  design, 
research  projects,  and  problem  solving.  While  the  scientific  and  engineering  applications 
were  up  to  standards  and  followed  sound  professional  practices,  USACE  realized  that 
improvement  was  necessary  in  the  business  practices  underlying  management  information 
systems. 

1.  Philosophy  towards  Management  Information  Systems  prior  to  1982 
The  standard  Corps  of  Engineers  Management  Information  System  (COEMIS)  was 
developed  in  1968.  Table  4  provides  a  list  of  information  systems  included  in  COEMIS. 
These  information  system  applications  were  used  by  USACE  personnel  worldwide,  and 
had  become  increasingly  important  to  the  effectiveness  of  the  USACE  mission. 

USACE  did  not  always  view  information  as  a  valuable  resource  that  can  be 
harnessed  to  increase  the  effectiveness  of  an  organization.  Preoccupied  with  growth 
issues,  top  management  within  USACE  did  not  provide  necessary  mechanisms  — 
planning,  control,  direction,  and  funding  —  to  ensure  that  information  resources  were 
effectively  utilized. 

In  1982,  the  management  of  information  systems  within  USACE  was  disparate 
and  inconsistent.  Dispersed  organizations  within  USACE  were  permitted  to  manage, 
acquire,  and  use  computers  in  the  way  they  saw  fit.  ADP  management  responsibilities 
were  widely  dispersed  among  the  central  office,  various  program  offices,  and  field 
offices  in  divisions,  districts,  research  centers,  and  laboratories.    There  was  no  real 
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SYSTEM 

FUNCTION 

FINANCE  AND 
ACCOUNTING 

Covering  all  district  level  accounting  records  for 
civil,  military,  and  revolving  fund  accounts. 

PERSONNEL 
ADMINISTRATION 

Database  for  staff  management  requirements  and 
authorizations. 

RESOURCE 

ALLOCATION/ 

PROJECT 

MANAGEMENT 

Reports  project  management  information  available  in 
the  personnel  and  finance  and  accounting  data  files. 

OTHER  SYSTEMS 

Transportation  Information  System,  Computer  Aided 
Engineering  and  Design,  Progress  and  Divisions 
reporting  system. 

Table  4.  US  ACE  Information  Systems  Prior  to  1982 


central  authority  for  managing  resources.  The  Engineering  Automation  Office  was 
established  as  a  central  point  of  management  for  ADP,  but  it  was  given  no  clear  authority 
over  the  smaller  district  offices.  As  a  result,  any  attempt  to  enforce  a  centralized  policy 
was  frustrated  by  the  decentralized  management  structure. 

2.        Effects  of  Disparate  Management  Philosophy 

USACE  had  numerous  ADP  activities  dispersed  worldwide,  accompanied  by 
inconsistent,  incomplete,  and  ineffective  planning.  According  to  GAO,  the  systems  that 
did  exist  appeared  to  be  fragmented  and  ineffective,  the  use  of  computer  equipment 
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throughout  USACE  was   inconsistent,   and   attempts  at  acquisition   of  modernized 
equipment  were  futile.   Table  5  summarizes  the  findings  of  a  GAO  report  in  1982.15 


GAO  FINDINGS 

No  single  focus  of  responsibility  or  coherent  system  for  managing 
information  resources 

Lack  of  a  formal  oversight  mechanism  to  ensure  effective  and 
efficient  management  and  use  of  information  systems  and  computer 
software 

No  policy  for  enforcing  control  of  the  development  of  software 
applications 

No  comprehensive  plan  to  help  manage,  acquire,  and  use 
information  resources 

No  uniform  method  for  evaluating  the  use  and  performance  of 
computers  and  related  information  resources. 


Table  5.  Shortcomings  Identified  in  GAO  Audit 


15Because  of  continual  requests  for  increased  funding  for  information  systems  by  USACE, 
the  House  Appropriations  Committee  requested  that  GAO  conduct  a  detailed  investigation  of 
USACE  information  systems  management  (GAO/CED-82-83).  The  audit  was  intended  to  answer 
the  following  questions: 

•  What  was  the  current  status  and  cost  of  resources  in  USACE? 

•  Did  the  USACE  have  an  effective  management  control  system  for  its  ADP  resources? 

•  Was  there  adequate  management  control  and  conversion  planning  for  computer  software? 

This  audit  highlighted  several  shortcomings  in  USACE  management  of  information 
resources  as  depicted  in  Table  5.  These  were  a  direct  result  of  the  inconsistent  management 
philosophy  practiced  by  USACE. 
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Most  notable  was  the  observation  that  there  were  no  uniform  or  standardized 
procedures  for  systems  development.  Although  USACE  had  attempted  to  standardize  and 
monitor  systems  development  by  requiring  that  any  development  expense  in  excess  of 
$10,000  be  approved  by  the  Engineering  Automation  Office,  there  were  no  mechanisms 
in  place  to  enforce  the  policy.  For  the  most  part,  systems  planning  took  place  within 
separate  directorates,  with  no  structured  methodology  in  place  to  integrate  system 
development. 

This  fragmented  approach  led  to  the  creation  of  vertical  un-integrated  "stovepipe" 
systems  designed  to  meet  the  specific  needs  of  departmentalized  functional  areas.  Some 
critical  data  were  unavailable  at  the  corporate  level;  when  available,  they  were  either 
redundant,  inconsistent,  or  inaccessible.  Programs  were  cumbersome  to  run,  with 
overlapping  modules. 

The  findings  of  the  audit  led  to  a  compilation  of  a  list  of  comprehensive 
recommendations  for  improvement  (Table  6). 


D.      Transition  to  CIM 

The  basic  philosophy  and  fundamental  principles  of  the  USACE  program  for 
Information  Resource  Management  were  outlined  in  March  of  1983.  The  objective  of 
the  IRM  program  was  to  improve  the  accuracy,  completeness,  availability,  timeliness, 
and  usefulness  of  information  for  decision  makers  at  all  levels.  The  time  line  of  this 
program  is  depicted  in  Table  7. 

In  June  of  1984,  USACE  completed  an  Information  Systems  Plan  (ISP)  for  the 
Office  of  the  Chief  of  Engineers,  presenting  the  results  of  a  pragmatic,  step-by-step 
review  of  USACE  information  systems.16  Three  objectives  were  identified:  relate 
information  requirements  to  mission,  goals,  and  information  systems;  recommend 
strategies  to  improve  IRM;  and  develop  an  action  plan  for  improvement.    Through  a 


16"Information  Systems  Plan  for  the  Office  of  the  Chief  of  Engineers",  June  1984. 

31 


• 


GAO  RECOMMENDATIONS 

Establish  a  separate  Information  Resource  Management  Office  at  the 
Headquarters  level  with  clearly  defined  authority  over  information 
resource  activity.  The  head  of  this  office  should  be  designated  by 
the  Chief  of  Engineers. 

Direct  the  senior  IRM  official  to  develop  and  implement  a 
comprehensive  program  for  managing  USACE  information 
resources. 

Establish  a  comprehensive  planning  process  for  information 
resources. 

Systematically  update  and  define  functional  user  requirements  to 
better  justify  the  acquisition  of  additional  computer  resources,  and 
determine  requirements  of  communication. 

Perform  a  detailed  review  and  analysis  of  major  software  systems 
to  determine  whether  they  should  be  continued,  redesigned,  or 
eliminated. 

Conduct  a  thorough  cost/benefit  analysis  of  alternative  redesign 
stratagem  for  USACE  Management  Information  Systems  to  assure 
that  the  Government  incurs  the  lowest  total  life  cycle  cost. 


Table  6.  GAO  Recommendations 


series  of  interviews  with  55  functional  managers,  a  consensus  was  reached  on  key  IRM 
issues  that  must  be  addressed  in  the  modernization  program.  Table  8  lists  these  issues 
in  order  of  priority.  The  team  realized  that  these  issues  must  be  effectively  addresses  in 
the  modernization  program  (Table  9). 

Following  completion  of  the  ISP,  the  Chief  of  Engineers  directed  that  an 
Information  Systems  Planning  Implementation  (ISPI)  report  be  written  dealing  with  the 
integration  of  information  systems  within  the  Office  of  the  Chief  of  Engineers.17 
Completed  in  May  of  1985,  the  report  developed  application,  data,  and  geographic 


17 "Information  Systems  Planning  Report:  A  Prescription  for  Change",  May  1985. 
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TRANSITION  TO  CIM 

1982 

GAO  Audit 

JAN  1983 

Modernization  Goals  and  Objectives  Outlined 

JUN  1984 

USACE  Information  System  Planning  Report 
Published 

AUG  1984 

Information  Resource  Management  Steering 
Committee  Established 

SEPT  1984 

Director  of  Information  Management  Established 

MAY  1985 

USACE  Information  Systems  Planning 
Implementation  Report  Published 

MAY  1986 

Comprehensive  Business  Re-Engineering  Program 
Commences 

DEC  1989 

12  Requirement  Statements  Completed 

1990 

26  Prototype  Modules  Completed 

AUG  1990 

USACE  1995  Architecture  Developed 

PRESENT 

10  Modules  Deployed 

Table  7.  CIM  Transition  Timeline:  Some  Notable  Actions 


architectures  for  USACE-wide  information  systems. 

The  report  contained  three  major  sections.  The  first  was  a  tactical  plan  that 
contained  recommendations  as  to  how  USACE  could  adjust  its  current  systems  planning 
methods  to  provide  for  greater  integration  within  the  framework  of  the  recommended 
architecture.  The  plan  recommended  a  reorientation  of  existing  resources  to  provide  for 
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Problem  Category 

Manifestations 

Lack  of/or  incomplete  automated 
system 

No  automated  information  system  available  to  satisfy  a 
perceived  need  or  a  system  substantially  inadequate. 

Lack  of  usefulness 

Provides  information  in  quantity  or  format  that  is  either 
not  desired  or  not  needed. 

Inadequate  ADP  assistance 

A  lack  of  command  direction,  central  database 
administration,  or  programming  capability  prevents 
effective  automation. 

Unreliable  area 

Data  are  not  accurate  or  consistent. 

Redundancy  of  data  and  systems 

Same  data  are  maintained  in  more  than  one  system,  and 
several  systems  are  designed  to  provide  the  same 
information. 

Untimeliness  of  output 

Data  are  received  too  late  to  be  useful  in  understanding 
program  status  or  effecting  changes. 

Incompatibility  of  automated  system 

Communications  among  information  systems  are 
restricted  by  hardware,  software,  or  data  design 
differences. 

Lack  of  interactivity 

Users  are  not  able  to  manipulate  or  select  data  from 
USACE  standard  information  systems. 

Inadequate  ADP  system  awareness 

Insufficient  training  for  users  of  automated  systems  and  a 
lack  of  aggressive  orientation  into  existing  systems, 
which  restrict  the  widest  use  of  automated  data. 

Lack  of  information 

No  system  exists  —  automated  or  non-automated  —  to 
provide  the  required  information. 

Inadequate  non-automated  systems 

Non-automated  systems  exist,  but  are  inadequate 

Technically  inadequate  ADP  systems 

A  lack  of  ADP  hardware,  software,  and/or 
communications  capability  prevents  effective  automation. 

Proprietary  systems 

"Owners"  of  automated  systems  resist  the  sharing  of 
"their"  data  with  others. 

Resource  Costs 

Costs  verses  benefits  are  difficult  or  impossible  to 
identify. 

Table  8.  Key  IRM  Issues  Identified  in  ISP 
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AREA 

RECOMMENDATION 

Education  of  Executives 

Implement  an  intensive  program  of  education 

concerning  automation,  software,  interactive 

capabilities,  ADP  cost  effectiveness,  and 

information  management. 

Management  of  Information/ 

Establish  a  strong  support  organization  for 

Automation 

information  resource  management. 

Implement  an  Information  Resource 

Management  Directorate  headed  by  a 

General  Officer  or  Senior  Executive  Service 

Civilian. 

Existing  System  Deficiencies 

Integrate  existing  systems  across  functional 

organizations. 

Lack  of  Automation 

Automation  should  be  developed  where 

needed.   Personnel  and   manpower  databases 

and  office  automation  support  should  be 

improved. 

ADP  Assistance 

Improve  coordination  and  teamwork  between 

ADP  community  and  US  ACE  managers. 

Table  9.  Recommendations  by  ISP  Team 


coordinated  information  and  system  planning  of  major  systems  under  the  direction  of  the 
Information  Resource  Management  Steering  Committee  created  in  August  1984. 

The  second  major  subsection  of  the  ISPI  report  was  the  project  slate.  The  report 
identified  applications  that  should  be  redesigned  to  make  them  more  consistent  with  the 
proposed  architecture  and  more  useful  to  management.  Seventeen  system  design  projects 
were  identified  and  ranked  in  order  of  importance  based  upon  potential  benefits,  impact 
on  the  organization,  probability  of  success,  and  demand  for  use  (Table  10). 
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PROJECT  SLATE 

(Ranked  by  Priority) 

1)  Finance  and  Accounting 

10)  Real  Estate 

2)  Manpower 

1 1)  Procurement  &  Supply 

3)  Design  Tracking 

12)  Civil  Works  Operations 

4)  Construction  Tracking 

13)  Administrative  Support 

5)  Civil  Works  Program  Development 

14)  Strategy,  Goals  &  Objectives 

6)  Data  Dictionary 

15)  Army  Facility  Program  & 

Budget 

7)  Command  Operating  Budget 

16)  Performance  Measurement 

8)  Civilian  Personnel 

17)  Safety 

9)  Plant  Replacement  and 

Improvement  Program  (PRIP) 

Table  10.  Project  Slate 

The  third  area  of  the  ISPI  report  was  the  information  architecture  review. 
Detailed  architectures  designed  to  serve  as  a  framework  for  future  systems  development 
were  defined.  They  were  intended  to  be  used  as  a  tool  for  planning  and  coordinating 
information  needs  over  the  life  of  the  Information  Systems  Modernization  Plan. 

In  May  of  1986,  US  ACE  began  a  comprehensive  business  re-engineering  program 
adopting  the  Structured  Requirements  Analysis  Planning  (STRAP)  Methodology  that  was 
aimed  at  building  shared  data  systems.  From  the  ISP  project  slate  (Table  10),  eight 
business  processes  were  identified  as  a  priority  for  systems  re-engineering  (Table  11). 
These  business  processes  were  systematically  reviewed  and  restructured  utilizing  the 
US  ACE  methodology  for  business  re-engineering.  This  methodology  has  proved  itself 
to  be  very  successful,  and  is  the  primary  focus  of  this  report.  The  process  of  re- 
engineering  continues  today  throughout  USACE. 
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CRITICAL  BUSINESS  PROCESSES 

• 

Project  Management 

• 

E-MAIL  and  Encyclopedia 

• 

Financial  Management 

• 

Contracts  and  Databases 

• 

Real  Estate 

• 

Employee  Data  Extract 

• 

Programs  Management 

• 

PAX  Data  Extract 

Table  1 1 .  Critical  Business  Processes 


1.        US  ACE  Corporate  Architecture  Strategies 

USACE  formally  adopted  a  new  information  architecture  with  the  target  goal  of 
complete  implementation  by  1995.18  The  primary  emphasis  of  the  new  architecture  is 
on  a  communication  network  with  increased  information  access,  interconnectivity,  and 
consolidation  of  data  centers.  USACE  organizations  and  field  offices  will  be  able  to 
access  the  network  from  remote  sites  through  a  device  interface  (DI),  a  remote  job  entry 
device,  or  gateways.  The  data  centers  located  in  Vicksburg,  Mississippi,  Rockville, 
Maryland19,  and  Portland,  Oregon  will  form  the  crux  of  the  network  and  will  be  linked 
by  a  common  telecommunications  backbone.  Application  programs  will  be  shared  among 
USACE  agencies,  and  will  be  accessible  by  several  functional  users  simultaneously. 
There  will  no  longer  be  overlapping  development  of  separate  systems  by  functional 
elements  within  USACE. 

As  a  result  of  the  interconnectivity  discussed  above,  databases  and  applications 
will  be  shared  and  centralized.  USACE  databases  will  be  dynamic  and  contain  standard 
data  elements  that  will  be  used  by  all  functional  elements  within  the  organization.  In  the 
new  architecture,  data  are  viewed  as  a  resource  separate  from  applications.   These  data 


18 "Information  Planning  Guidance:  Towards  building  the  1995  Corporate  Architecture", 
May  1991. 

19Rockville,  Maryland  site  is  contractor  owned  and  will  not  be  used  for  processing. 
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should  be  captured  once  at  the  source  and  then  shared  by  all  users.  USACE  will  rely 
on  the  minimal  essential  data  to  get  the  job  done.  Data  will  no  longer  be  redundant  and 
unstandardized.  The  overall  goal  is  to  improve  the  accuracy,  consistency,  and  timeliness 
of  data,  and  to  facilitate  access  to  information. 

2.        Leadership  Support  and  Executive  Champions  for  Change 

Leaders  within  USACE  are  actively  involved  in  the  modernization  program, 
supervised  by  the  Deputy  Commanding  General  of  the  Army  Corps  of  Engineers,  the 
second  highest  ranking  officer  within  USACE.  As  the  senior  IRM  official,  he  has 
overall  responsibility  for  information  resource  management. 

Committees  are  an  essential  facet  of  the  modernization  program.  The  role  of 
these  committees  is  to  drive  USACE  through  its  modernization  effort.  Critical  to  the 
success  of  the  program  is  the  participation  by  "executive  champions"  who  are  willing  to 
take  risks  and  make  changes  in  the  way  USACE  manages  its  information  resources. 
USACE  seeks  out  these  committee  members  who  are  functional  managers  willing  to  try 
new  methods  and  re-engineer  business  practices. 

Figure  6  shows  the  committees  and  their  functions.  The  senior  governance  board 
is  the  Information  Resource  Management  Steering  Committee  (IRMSC).  It  is  comprised 
of  twelve  voting  members  at  the  General  Officer  or  Senior  Executive  Service  level  who 
are  appointed  by  the  Deputy  Commanding  General.  Also  included  as  non-voting 
members  are  the  Program  Managers  for  the  Information  Systems  Modernization 
Program,  the  Hardware  Acquisition  Program,  and  the  Director  Of  Information 
Management.  The  members  of  the  committee  are  all  top-level  functional  managers  who 
make  decisions  for  USACE.  The  Committee  meets  as  required,  but  no  less  than 
quarterly. 

The  Executive  Committee  is  a  seven-member  subset  of  IRMSC  that  meets  weekly 
and  is  designed  to  "keep  the  pressure  on"  the  program  managers  and  the  players  in  the 
modernization  program. 
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Figure  6.    Information  Resource  Management  Committees 


There  are  three  subcommittees  operating  under  IRMSC.  The  Automation 
Configuration  Management  Board  is  chaired  by  the  Director  of  Information  Management 
and  involves  top  management  in  the  acquisition  and  utilization  of  automation  and 
communications.  The  Data  Scrub  Review  Committee  consists  of  functional  managers 
formed  on  an  ad  hoc  basis  to  addresses  data-specific  issues  within  a  given  business 
process  area.  The  final  subcommittee,  the  Information  Systems  Modernization  Program 
(ISMP)  Proponents  Group,  advises  the  Modernization  Program  Manager  on 
modernization  efforts  in  all  business  areas. 
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E.       Components  of  the  Evolving  Information  Systems 

The  Corps  of  Engineers  sees  its  future  information  systems  evolving  into  five 
integrated  application  groups  (Table  12).  Of  highest  priority,  Group  One  systems  are 
those  that  have  been  initially  identified  as  candidates  for  re-engineering  (Table  11). 


IS  GROUPING 

DESCRIPTION 

APPLICATION* 

GROUP  1 

Drivers 

Financial  Management 

High  degree  of  shared 

Payroll 

data 

Real  Estate 

Critical  to  USACE 

mission 

GROUP  2 

Compliment  Group  1 

Safety  Information 

Subject  Specific 

Management  Database 
Navigable  Waterways 
subject  database 

GROUP  3 

Housekeeping 

National  Inventory  of 

Highly  subject 

Dams 

specific 

Career  Program 

Broad  Spectrum  of 

Management  Database 

business  functions 

GROUP  4 

Decision  Support 

Executive  Information 

GROUP  5 

Library  and  legal 
support 

Historic  Databases 

*  Representative  listing 

Table  12.  USACE  Information  Systems  Groupings 


40 


IV.    US  ACE  Re-Engineering  Process 


As  a  result  of  the  modernization  effort,  USACE  has  developed  an  innovative 
approach  to  business  re-engineering  that  results  in  the  evolution  of  critical  information 
systems  in  support  of  major  business  processes  or  missions.20  The  methodology 
incorporates  the  use  of  a  technique  adapted  for  USACE  needs.  The  final  result  is  a 
pragmatic  and  adaptive  approach  to  IS  development. 

A.      USACE  -  A  Pragmatic  Approach  to  Information  Systems 
Development 

As  shown  in  Figure  7,  USACE  has  outlined  a  strategy  consisting  of  four  major 
organizational  activities  and  their  IS  counterparts. 

1.        ISP/ISPI  Completion 

The  first  step  in  any  modernization  program  is  the  completion  of  strategic  and 
tactical  plans  that  form  the  foundation  for  business  re-engineering.  USACE  strategy 
incorporates  the  use  of  the  Information  Systems  Plan  (ISP),  and  the  Information  Systems 
Planning  Implementation  (ISPI)  report. 

The  ISP  provides  a  strategic  plan  that  relates  information  requirements  to  mission 
goals  and  objectives.  An  information  architecture  is  defined,  and  an  action  plan 
recommending  specific  improvement  activities  is  set  forth. 

USACE  efforts  included  the  use  of  the  Headquarters  level  ISP,  conducted  in 
1984,  and  57  field  level  ISP's  conducted  between  1984  and  1989. 


20With  or  without  information  systems  support,  the  organization  still  has  to  deal  with  technical 
difficulties  that  are  inherent  in  the  way  it  conducts  business. 
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Figure  7.  Mapping  USACE  IS  Activities  to  Organizational  Counterparts 


Following  the  ISP,  an  ISPI  is  produced.  This  tactical  plan  establishes  information 
architectures,  creates  project  slates,  and  establishes  the  IS  management  structure.  The 
ISPI  project  slate  identifies  candidates  for  re-engineering  that  form  the  foundation  of  the 
modernization  effort.  Again  USACE  efforts  included  both  headquarters  and  field  level 
ISPI's. 


2.        Business  Re-Engineering  Process  Model  —  Producing  the  Structured 
Requirement  Analysis  and  Planning  (STRAP)  Report 

Process  and  data  requirements  of  a  particular  functional  application  area  are 
analyzed  and  documented  in  the  Structured  Requirements  and  Analysis  Planning  (STRAP) 
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Report.  Producing  this  report  uses  a  team  approach  that  involves  functional 
participation.  Business  activities  are  modeled,  and  result  in  a  blueprint  for  further 
development.   Figure  8  describes  the  business  process  re-engineering  model. 

a.        Selection  of  Team  Members  and  Team  Composition 

Once  an  existing  application  has  been  identified  as  a  candidate  for  re-engineering, 
an  application  development  team  must  be  formed.  The  project  leader  is  assigned 
approximately  two  weeks  in  advance  of  the  start  of  the  actual  development  effort  to 
prepare  for  the  task  at  hand.  The  project  leader  serves  as  both  a  working  member  of  the 
team  and  as  team  leader,  assuming  a  position  of  coordination  between  the  team  and  the 
sponsor  of  the  application  being  developed.  This  role  calls  for  business  system  skills  as 
well  as  effective  leadership  abilities. 

Application  development  teams  vary  in  size  depending  upon  the  application 
developed  and  the  skills  possessed  by  the  various  members  of  the  team.  In  general, 
teams  consist  of  six  to  eight  individuals,  with  additional  functional  members  on  call  to 
support  the  team  if  requested.  STRAP  team  members  are  selected  by  the  project 
proponents  with  the  following  used  as  criteria  for  team  selection: 

•  A  good  working  knowledge  of  USACE  policies  which  impact  their  functional 
areas  and  a  knowledge  of  USACE  policies  as  a  whole. 

•  Broad  experience  which  transverses  different  functional  areas  and  organizational 
levels  within  USACE. 

•  A  manager  or  assistant  in  multidisciplinary  area. 

STRAP  team  members  must  be  experienced  with  the  overall  mission  and  business 
practices  of  USACE.  They  must  be  willing  to  try  new  methods  and  apply  innovative 
ideas  to  application  development.  Table  14  depicts  the  generic  team  composition  and  the 
roles  fulfilled  by  team  members.   Most  of  the  members  come  from  USACE  with  a  few 
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Figure  8.  Business  Process  Re-Engineering  Model 
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contractors  providing  instruction,  modeling  and  administrative  support.21 


ROLE 

PROJECT  LEADER 
FACILITATOR 

FUNCTIONAL  USERS 

-  SUBJECT  MATTER  EXPERTS 

-  LIBRARIAN 

-  USER  MANUAL  DOCUMENTER 

REVIEWER 
END  USERS 

APPLICATION  DEVELOPERS 

-  TECHNICAL  LIBRARIAN 

-  USER  MANUAL  DEVELOPER 

HARDWARE/SOFTWARE  SUPPORT 
DATA  ADMINISTRATOR  SUPPORT 
ADMINISTRATIVE  SUPPORT 


Table  14.  Generic  Team  Composition 


The  facilitator  is  a  US  ACE  employee  or  a  contractor  knowledgeable  in  application 
development  tools  and  techniques  (i.e.,  IDEF  tools  and  prototyping)  and  data-driven 
user-oriented  information  systems. 


21  "U.S.  Army  Corps  of  Engineers  Information  Engineering:     Application  Development 
Project  Leaders  Reference  Manual",  March  1,  1991. 
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A  Junctional  user  must  have  a  broad  perspective  of  how  the  USACE  conducts 
operations  in  his  or  her  functional  area.  Users  come  from  a  wide  range  of  management 
levels  within  USACE,  and  are  key  to  the  success  of  the  application  development  process. 

The  librarian  collects,  catalogs,  and  maintains  sample  reports,  documentation,  and 
any  references  that  a  team  may  use  during  the  development  process.  The  technical 
librarian  is  responsible  for  the  management  of  the  software  tools  being  used  as  the 
application  modules  are  developed,  and  for  keeping  logs  of  the  latest  updates. 

The  data  manager  performs  both  data  administration  and  database  administration 
functions  for  the  project.  He  or  she  maintains  the  conceptual  data  model  as  well  as  the 
physical  model. 

Application  programmers  should  possess  strong  programming  skills  in  high-level 
computer  languages,  particularly  4GLs  or  I-CASE  products.  They  may  be  involved  in 
the  development  of  activity  models  with  functional  team  members  in  order  to  gain  an 
understanding  of  the  relationships  represented  by  the  models.  Programmers  transform 
the  functional  description  into  the  actual  working  application. 

b.         Training  of  Team  Members 

Team  members  must  possess  a  wide  variety  of  skills  to  ensure  a  successful 
application  development  effort.  They  must  have  knowledge  concerning  all  phases  of  the 
application  development  process  and  the  skills  listed  in  Table  15.  Each  member  need  not 
possess  all  skills,  and  not  every  application  requires  all  of  these  skills,  yet  they  are 
representative  of  the  skills  required  to  develop  an  application  successfully. 

Team  members  initially  were  trained  in  modeling  techniques  and  application 
development  by  personnel  working  under  contract  for  USACE.22  After  this  initial 
training,  USACE  uses  its  own  personnel  to  train  future  team  members. 


^USACE  training  was  conducted  by  D.  Appleton  Company.    The  approximate  cost  of  this 
training  (10-15  people)  was  $10. 5K. 
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DEVELOPMENT  PHASE 



REOUIRED  SKILLS 

Planning  Requirements  and  Design 

•ISMP  goals  and  objectives 

•LCMIS  and  information  engineering 

•Application  development  project 

methodology 

•IDEF  modeling  techniques  overview 

•USACE  data  administration  goals  and 

objectives 

Development  of  Interactive  Relational 

•Relational  database  concepts 

Database  Information  Systems 

•Oracle  and  SQL  for  developers 

•COBOL  programming  for  SQL  databases 

•Oracle  client  server  architecture 

Data  and  Database  Administration, 

•Oracle  database  administration, 

Performance  Tuning 

application  tuning,  and  client  server 

performance  analysis 

•NOS/VSE  file  management  optimization 

and  communications  in  the  client  server 

mode 

Functional  User  Design  and  Evaluation 

•Introduction  to  SQL  for  end  users 

•Oracle  for  end  users 

•SQL  forms  and  report  writers  for  end 

users 

Concepts  and  Operations  of  New 

•Conversion  tool  use 

Applications 

•Manual  conversion  procedures 

•Overview  of  conceptual  design  of 

application 

•Procedures  for  the  new  application 

Table  15.  Skill  Requirements 


c.         Conduct  Activity-Based  Costing  Baseline 

The  main  purpose  of  the  ABC  baseline  is  to  acquaint  members  with  the  design 
tools  (i.e.,  IDEF).  Some  participants  are  familiar  with  current  business  practices, 
operating  procedures,  and  costs  of  activities.   IDEF  techniques  are  used  to  model  these 
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processes  ("AS-IS"  models).    This  gives  team  members  the  opportunity  to  experiment 
and  become  proficient  in  IDEF  modeling. 


d.  Conduct  Activity-Based  Cost  Alternatives 

After  the  business  process  is  broken  down  into  distinct  activities  in  the  "AS-IS" 
models,  ABC  is  then  used  to  analyze  activity  models  (see  Appendix  B).  Activities  are 
determined  to  be  either  value-added  or  non-value  added.  A  non-value  added  activity 
becomes  a  candidate  for  elimination  or  improvement.  The  results  of  the  ABC  analysis 
form  the  baseline  for  improvement  action  within  the  business  process. 

e.  Implement  Improvement  Actions 

An  important  step  is  to  identify  changes  to  the  business  process  that  can  be 
improved  without  further  analysis  or  approval.  These  improvement  opportunities  will 
be  the  foundation  for  the  formulation  of  "TO-BE"  process  models  which  are  formulated 
in  the  next  phase  of  the  business  re-engineering  methodology. 

/         Conduct  Business  Process  Modeling 

Once  the  current  system  is  analyzed  and  improvement  actions  identified,  the  team 
once  again  uses  IDEF  techniques  to  build  "TO-BE"  activity  and  data  models  of  the 
system.  These  "TO-BE"  models  show  how  the  business  activities  will  perform  once 
they  are  modernized.  They  are  developed  from  the  ground  up  with  little  or  no  reference 
to  the  existing  process.  Team  experience  and  knowledge  of  the  functional  area  being 
covered  allow  them  to  develop  the  future  systems  as  they  would  like  to  see  them 
operate.  Usually,  more  than  one  "TO-BE"  model  is  developed  to  examine  alternatives 
before  deciding  on  the  final  one.  An  initial  data  model  is  developed  by  extracting  a 
subset  of  the  command  data  model.23  Additional  data  elements  are  added  to  the  model 


23The  Command  Data  Model  (CDM)  is  a  graphical  depiction  of  all  USACE  entities,  data 
elements,  and  their  relationships.  This  model  is  continually  being  developed  as  part  of  the  overall 
modernization  effort.     The  CDM  provides  the  basic  framework  for  all  business  systems 
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as  necessary  after  approved  by  the  Data  Scrub  Review  Committee  for  use  throughout 
USACE. 

g.        Build  Business  Case 

The  "TO-BE"  models  developed  are  now  examined  and  evaluated.  For  each 
alternative,  costs  are  identified,  potential  benefits  determined,  and  risks  assessed.  This 
economic  analysis  serves  as  a  basis  for  selecting  the  model  to  be  developed. 

h.        Develop  Transition  Plan 

The  team  must  develop  a  project  implementation  plan.  Included  in  this  plan  is 
the  preferred  project  solution  alternative  and  the  reason  for  selecting  it.  The  staging, 
resourcing,  and  sequencing  of  related  actions  are  determined  and  a  preliminary  project 
schedule  is  drafted. 

The  final  result  of  the  business  re-engineering  methodology  is  the  STRAP  report. 
This  report  constitutes  the  foundation  upon  which  targeted  applications  will  be  developed. 
It  consists  of  the  functional  specifications  of  a  proposed  information  system  —  i.e.,  the 
"TO-BE"  activity  model  and  its  corresponding  data  model  along  with  the  proposed 
milestones  for  project  completion. 

4.       Prototype  Development  Concept  —  from  Design  to  Implementation 

Prototype  Development  Concepts  (PDC'S)  are  more  technical  in  nature  than  the 
STRAP  and  provide  the  details  necessary  to  actually  build  the  systems  defined  in  the 
STRAPS.  The  result  is  a  fully  working  prototype  that  will  be  deployed  for  US  ACE- wide 
use. 


development  depending  on  shared  data. 
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a.  Conceptual  Design 

Following  the  conceptual  development  and  planning  phase,  functional 
requirements  defined  in  the  STRAP  report  are  translated  into  a  functional  design 
description. 

User  application  interfaces,  bridges  to  other  systems  within  USACE  corporate 
architecture,  and  documentation  of  the  necessary  business  controls  are  defined.  The 
technical  requirements  for  hardware,  software,  communications,  security,  and 
performance  are  also  specified  at  this  time. 

Finally,  the  team  surveys  existing  software  applications  that  might  be  re-used  as 
part  of  the  proposed  system.  It  also  establishes  guidelines  for  the  procurement  process 
if  such  an  application  is  available  and  selected.  No  selection  is  made  at  this  time  as  to 
whether  or  not  an  existing  "commercial  off  the  shelf  (COTS)  application  will  be 
procured  by  USACE. 

b.  Acquire  Application 

The  acquisition  phase  uses  the  design  documentation  and  the  list  of  existing 
available  COTS  applications  to  evaluate  the  packages  available  from  commercial  vendors 
or  other  government  agencies.  A  Request-for-Proposal  is  drafted  from  the  functional 
description  and  sent  to  potential  COTS  suppliers.  Proposals  received  from  suppliers  are 
evaluated  and  the  functional  capabilities  are  compared  with  the  requirements  defined  in 
the  STRAP.  The  databases  of  the  proposed  systems  are  evaluated  and  a  data  model  of 
the  system  is  prepared  to  compare  how  thoroughly  the  proposed  system  databases  meets 
the  data  requirements  of  the  USACE  model  system.  If  an  off-the-shelf  system  is 
selected,  a  contract  for  modification,  transfer  of  technology,  and  maintenance  is 
negotiated  with  the  supplier.  Eventually,  the  selected  COTS  system  will  become  an 
integral  part  of  the  proposed  system. 
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c.  Iterative  Application  Development 

If  no  COTS  application  meets  USACE  specifications  a  new  application  must  be 
developed.  Beginning  with  the  functional  description  written  during  the  design  phase, 
a  prototype  of  the  application  is  developed.  The  key  to  the  success  of  prototyping  is  to 
involve  functional  users  in  the  continual  evaluation  and  improvement  of  the  system  being 
developed.  During  this  iterative  process,  users  participate  in  the  testing  and  evaluation 
of  the  emerging  system,  noting  its  deficiencies  and  suggesting  design  improvements. 
Corrections  and  enhancements  are  then  made,  and  the  improved  version  is  resubmitted 
to  users  for  evaluation.   The  functional  description  is  updated  to  reflect  the  changes. 

When  all  of  the  components  of  the  application  have  been  developed,  they  are 
integrated  in  preparation  for  "alpha  testing"  —  i.e.,  internal  systems  testing.  The 
functional  description  is  updated  and  finalized,  all  program  modules  are  recompiled  and 
loaded,  the  test  database  and  user  documents  are  reviewed,  and  a  proposed  operations 
manual  is  drafted. 

The  integrated  application  undergoes  a  comprehensive  functional  test  that 
encompasses  user  application  interfaces,  bridges  to  other  USACE  information  systems, 
and  the  batch  programs.  Following  the  alpha  test,  an  in-process  review  is  conducted 
and  the  results  of  the  testing  are  evaluated  and  necessary  changes  are  made.  Following 
this,  approval  is  granted  for  advancement  to  "beta  testing"  —  i.e.,  testing  by  a  selected 
group  of  users. 

d.  Perform  Integration  and  Beta  Testing 

The  application  is  designed  to  fully  integrate  into  the  overall  USACE  architecture. 
Some  integration  is  done  during  the  system  development,  but  final  integration  with  the 
existing  architecture  is  normally  required. 

Corrections,  improvements,  and  enhancements  that  were  identified  during  the 
alpha  testing  are  programmed  at  this  time.  User  documentation  is  updated  to  reflect 
these  changes  and  the  system  is  integrated  with  the  Command  Data  Model.  A  second 
alpha  test  is  then  performed,  and  the  system  is  also  tested  in  the  environment  in  which 
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it  will  operate.    This  testing  aims  to  verify  that  the  new  application  will  operate  in 
conjunction  with  existing  systems. 

Beta  tests  are  performed  in  operational  environments  at  multiple  test  sites.  The 
new  application  is  installed  at  a  test  site.  Operators  and  end  users  are  trained  in  the  use 
of  the  application.  The  new  application  is  usually  operated  in  parallel  with  the  existing 
information  system  or  manual  procedures.  End  users  document  any  problems  that  arise 
as  a  result  of  the  new  application  and  evaluate  the  application  in  terms  of  effectiveness 
and  performance  level.  Upon  completion  of  the  beta  test,  another  in-process  review  is 
conducted  and  a  recommendation  is  made  for  either  deployment  or  continued 
improvement  of  the  application. 

e.         Perform  Operational  Transition  and  Deployment 

During  the  final  phase  of  business  re-engineering  procedure  the  application  is 
placed  into  operation. 

A  transition  plan  and  deployment  schedule  is  developed  that  considers  issues  such 
as  the  full-scale  conversion  of  data,  training  of  users,  training  of  operations  staff, 
bridging  the  system  into  currently  existing  systems,  and  scheduling  the  acquisition  of 
hardware,  software,  and  communications.  Actual  deployments  at  specific  sites  are 
scheduled  at  this  time. 

Following  these  steps,  the  application  is  packaged  for  delivery  to  end  users.  This 
involves  preparing  the  necessary  software,  documentation  materials,  and  training  plan. 
When  the  package  is  delivered,  the  application  development  team  turns  over 
responsibility  for  management  and  maintenance  to  the  appropriate  support  team.  This 
team  installs  the  actual  hardware,  software,  and  communications  required  at  each  site. 

The  final  step  in  the  implementation  involves  the  training  of  site  personnel, 
including  both  end  users  and  operators,  on  the  operation  of  the  new  application.  In 
addition,  local  management  is  briefed  on  the  scope  and  basic  functionality  of  the 
application. 
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When  the  entire  application  is  in  place  at  a  particular  site,  users  will  begin  to 
operate  the  new  system  either  in  parallel  with  the  existing  system  or  independently  as 
appropriate.  The  initial  six-month  period  is  used  to  provide  feedback  to  the  proponent 
in  the  effectiveness  of  the  new  application  and  to  propose  any  major  changes  that  may 
be  necessary.    Following  this  phase,  the  system  is  fully  operational. 
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V.    Lessons  Learned 


A.  Top  Management  Support  is  Critical 

The  commitment  and  support  of  top  management  is  critical  to  the  success  of  any 
business  re-engineering  effort.  Top  management  must  see  information  as  a  strategic 
asset,  link  re-engineering  to  mission  effectiveness,  and  fully  support  the  efforts  of  the 
information  modernization  team.  Any  fundamental  change  in  the  organization  is 
impossible  without  such  support.  As  the  second  highest  ranking  officer  within  USACE, 
the  senior  IRM  official  possesses  the  authority  commensurate  with  this  responsibility  to 
effect  change  within  the  IRM  organization. 

B.  Business  Re-engineering  Drives  Information  Systems  Design 

USACE  has  determined  that  85  percent  of  its  improvement  opportunities  are 
related  to  the  business  procedures  and  not  to  automation  alone.  This  is  critical  to 
understanding  the  importance  of  business  re-engineering.  Organizations  are  often 
enthusiastic  about  automation,  yet  they  must  realize  that  if  the  business  processes 
underlying  the  automation  effort  are  inefficient,  the  automation  will  be  futile. 

The  goal  of  business  re-engineering  is  to  rethink  the  way  an  organization  operates. 
Computer  systems  development  can  no  longer  be  solely  justified  as  a  means  of 
automating  existing  inefficient  business  practices.  The  systems  must  be  designed  to 
incorporate  new  and  innovative  business  practices.  These  practices  can  only  be 
discovered  through  an  extensive  business  re-engineering  effort. 

USACE  has  demonstrated  that  successful  re-engineering  is  dependent  on  an 
incremental  and  pragmatic  approach  to  business  process  re-engineering.  The  business 
processes  of  the  organization  must  be  broken  up  into  projects  of  manageable  size.   The 
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organization  must  not  attempt  to  re-engineer  without  an  understanding  of  the  underlying 
business  processes.  When  these  processes  are  understood  and  have  been  redefined,  they 
must  be  integrated  with  each  other  in  order  to  form  the  overall  business  process  for  the 
organization. 

A  focus  on  business  processes  does  not  in  any  way  minimize  the  critical 
importance  of  information  technology.  Although  technology  should  not  drive  changes 
in  business  processes,  it  often  enables  changes  that  would  otherwise  not  be  feasible. 

C.  Use  of  Committees  to  Solidify  Results 

Teamwork  constitutes  the  cornerstone  of  TQM.  Committee-oriented  decisions 
promote  cooperation,  non-hierarchical  posturing,  and  effective  problem  solving.  US  ACE 
has  demonstrated  adept  use  of  the  committee  decision  making  process  in  the  development 
of  management  information  systems.  Collaborative  group  work  is  especially  suitable  to 
re-engineer  mission-essential  applications. 

The  involvement  of  high  level  functional  managers  has  proven  to  be  a  key  to  the 
success  of  the  re-engineering  effort.  By  bringing  these  managers  together  and  forming 
a  top-level  decision  making  committee,  priorities  and  functional  specifications  can  be  set 
to  reflect  the  overall  mission  of  the  organization.  Collectively,  USACE's  IRMSC  and 
the  associated  Executive  Committee  and  sub-committees  determine  the  direction  of  future 
modernization  programs. 

D.  Involvement  of  Functional  Managers  is  Fundamental 

Critical  to  the  success  of  re-engineering  is  the  active  participation  of  functional 
managers  in  the  process.  Functional  managers  have  a  clear  understanding  of  the  business 
processes  taking  place.  Their  cooperation  with  the  information  resource  staff 
significantly  improves  the  quality  of  improvement  and  changes  to  the  systems.  New 
systems  tend  to  be  cross-functional  and  so  it  is  necessary  to  get  the  joint  participation  of 
all  functional  managers  whose  areas  of  responsibility  will  be  affected  by  a  system 
change. 
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E.  Role  of  a  Consultant 

Implementing  a  successful  information  system  calls  for  a  combination  of  a  sound 
understanding  of  the  business  process  and  a  strong  grasp  of  the  appropriate  information 
technologies.  It  is  fairly  unusual  for  an  individual  team  member  to  have  solid  credentials 
across  this  wide  spectrum.  The  team  as  a  whole  typically  encompasses  the  necessary 
business  and  technical  skills,  but  it  is  not  easy  to  integrate  across  such  disparate 
individual  backgrounds.  A  good  consultant  brings  to  a  project  a  broad  set  of  talents  that 
supplement  those  of  the  team.  The  skills  and  experience  necessary  to  do  this  well  are 
quite  rare.  Therefore  most  projects  cannot  employ  such  a  person  on  a  full-time  basis. 
A  consultant,  however,  may  be  able  to  contribute  concurrently  to  several  projects, 
thereby  leveraging  his  or  her  expertise  in  an  effective  way.  These  skills  may  be  obtained 
from  an  outside  consulting  firm  or,  very  often,  through  an  internal  staff  having  a 
similarly  broad  set  of  skills. 

F.  Role  of  Executive  Champions 

The  role  of  "executive  champions"  is  another  critical  success  factor.  Proponents 
of  a  modernization  program  must  seek  out  managers  at  all  levels  who  take  risks  and  are 
willing  to  try  new  and  innovative  business  methods.  They  must  not  be  afraid  to  change 
the  way  they  work  and  to  change  the  way  that  information  is  viewed  by  the  organization. 
The  managers  who  realize  that  successful  information  management  and  data  sharing  are 
key  to  the  increased  efficiency  of  operations  must  be  at  the  forefront  of  the  modernization 
program. 

G.  Need  for  a  Well-Structured  Methodology  and  Training 

A  successful  re-engineering  effort  is  dependent  upon  the  adoption  of  a  structured 
information  engineering  methodology  supported  by  a  commercial-off-the-shelf  (COTS) 
software  tool  that  can  be  tailored  to  meet  organizational  needs. 
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USACE  has  demonstrated  success  in  using  the  Structured  Requirements  Analysis 
and  Planning  (STRAP)  methodology,  a  process  in  which  the  information  requirements 
of  a  business  are  analyzed  and  documented,  and  has  proven  that  it  does  provide  a 
structured  approach  to  the  analysis  of  business  processes. 

Critical  to  the  success  of  such  a  methodology  is  the  training  of  the  individuals 
who  are  involved  in  the  re-engineering  efforts.  USACE  experience  has  demonstrated  the 
invaluable  benefits  of  having  trained  team  members  in  appropriate  areas  of  systems 
development,  particularly  areas  such  as  IDEF  and  ABC.  Training  and  orientation  require 
up-front  costs,  but  the  investment  is  essential. 

H.      Use  of  Activity-Based  Management  and  Costing  in  Conjunction 
with  IDEF  Activity  Modeling 

ABC  has  been  used  successfully  in  the  commercial  sector.  The  experience  of 
USACE  has  shown  that  DoD  agencies  can  incorporate  such  a  tool  into  a  comprehensive 
business  re-engineering  methodology.  This  methodology  is  being  exported  as  a  standard 
throughout  the  Department  of  Defense. 

USACE  has  demonstrated  that  ABC,  used  in  combination  with  well-proven 
structured  activity  and  data  modeling  techniques  such  as  IDEF,  provides  a  powerful  tool 
for  accomplishing  business  re-engineering.  Structured  techniques  allow  managers  to 
simplify  the  view  of  the  business  process  and  to  establish  a  well-defined  audit  trail  to 
support  the  continuous  review  process.  Furthermore,  ABC  techniques  provide  essential 
inputs  necessary  to  identify  activities  that  must  be  eliminated  or  improved. 


I.        Critical  Role  of  On-Line  User  Support 

The  role  of  on-line  user  support  is  crucial  to  the  future  of  systems  development. 
Realizing  this  critical  issue,  USACE  has  designed  its  systems  so  that  users  of  the 
systems  are  the  direct  recipients  of  the  data.  Whenever  possible,  the  role  of  an 
intermediary  —  i.e.,  a  computer  operator  —  between  the  systems  and  the  users  should 
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be  eliminated.   Managers  will  have  direct  and  fast  access  to  the  data  critical  to  making 
timely  and  correct  decisions. 

J.       Central  Role  of  Data  Modeling 

As  part  of  the  USACE  1995  architecture  goals,  data  are  viewed  as  critical  system 
resources.  Consistent  with  this  view,  USACE  has  moved  to  data  centralization  and 
standardization.  A  system  of  reviewing  and  approving  data  elements  was  developed,  it 
consists  of  three  steps:  submission  of  data  elements,  approval  by  the  data  scrub  review 
committee,  and  certification  as  standard  USACE  data  elements.  Currently  USACE  has 
approximately  2000  data  elements  at  the  "approved  level."  These  represent 
approximately  80  percent  of  the  data  elements  that  will  be  required  by  the  1995 
architecture.24 

Standardized  data  modeling  has  several  advantages.  During  the  data  review 
process,  USACE  realized  that  over  40  percent  of  its  current  elements  were  redundant, 
causing  added  costs,  errors,  and  inconsistencies.  With  data  standardization,  data  are 
separated  from  applications,  entered  once  at  the  source,  and  shared  by  all.  By  this 
means,  the  inconsistency  and  increased  overhead  associated  with  redundant  data  can  be 
substantially  reduced.  USACE  uses  only  the  essential  data  to  manage  its  information. 
This  minimization  of  data  elements  improves  information  quality,  timeliness,  and  access. 


^Spivey  Interview 
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CRITICAL  ISSUES 

USACE  IMPLEMENTATION 

LEADERSHIP 

•           Senior  Management                      • 

Deputy  USACE  commander  is  senior 

Commitment 

IRM  official 

MANAGEMENT 

•           Functional  managers  are  key         • 

IRMSC  comprised  of  top-level 

to  success 

functional  managers 

Application  development  teams  involve 

middle-level  functional  managers 

•           Change  Agents  essential                • 

Executive  champions  sought  at  all  levels 

•           Consensual  decision  making          • 

Use  of  committee  work  to  solidify 

results 

STRATEGY 

•           Re-engineering  effort  operates       • 

Use  of  a  well-established  and 

as  a  natural  business  process 

comprehensive  planning  program 

•           Business  process  drives  IS            • 

Re-engineering  business  processes  prior 

design 

to  automation 

METHODOLOGY 

•           Focus  on  business  processes         • 

Use  of  ISP,  ISPI,  and  STRAP 

methodologies 

•           Use  of  structured  methodology     • 

IDEF  in  conjunction  with  ABC 

that  can  be  universally  applied 

•           Data  modeling  and                        • 

Creation  of  the  command  data  model 

standardization  are  essential 

and  command  data  dictionary  in 

conjunction  with  USACE  data 

administration  program 

Table  16.  Summary  of  Lessons  Learned 
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Appendix  A.     An  Overview  of  the  IDEF  Technique 


IDEF  (Integrated  Computer  Aided  Manufacturing  Definition)  is  a  modeling 
technique  used  to  graphically  represent  business  processes.  Based  on  Structured  Analysis 
and  Design  Technique  (SADT)  developed  by  SOFTECH  in  the  1970' s,  IDEF  is  a 
structured  and  proven  methodology  that  has  been  widely  used  throughout  industry  and 
government.  IDEF  refers  to  two  diagramming  methods.  IDEFO  is  used  for  functional 
activity  modeling,  while  IDEF IX  is  used  for  data  modeling. 

The  IDEFO  modeling  technique  was  developed  by  the  U.S.  Air  Force  as  part  of 
their  Integrated  Computer  Aided  Manufacturing  (ICAM)  project.  The  goal  of  IDEFO  is 
to  provide  a  graphical  framework  for  hierarchically  decomposing  and  representing  the 
business  process  as  a  collection  of  related  functions  and  activities. 

Activities  are  the  center  of  IDEFO.  An  activity  is  an  action  that  occurs  within 
a  business  process  that  has  a  recognizable  outcome.  Symbols  are  used  to  represent 
activities  and  information  flows.  Activities  in  IDEF  are  represented  by  boxes  (Figure 
Al.)  The  text  within  the  box  is  the  name  of  the  activity  itself.  Activity  names  are 
typically  verbs  or  verb  phrases.  The  arrows  represent  information  flow  and  have  specific 
meanings.  Arrows  entering  the  left  side  of  the  activity  box  represent  inputs  —  those 
items  which  are  consumed  or  transformed  by  the  activity.  Controls  are  represented  by 
the  arrows  entering  the  top  of  the  box  and  are  those  factors  that  constrain  or  influence 
how  an  activity  is  to  be  performed  (i.e.,  existing  regulations,  prior  personnel 
commitments).  The  right  side  of  the  box  is  reserved  for  the  outputs  or  the  product  of 
the  activity.  The  arrows  entering  the  bottom  of  the  activity  box  represent  mechanisms 
—  the  people  or  tools  used  to  perform  the  activity. 

Collectively  these  information  flows  are  referred  to  as  "ICOMS"  (derived  from 
taking  the  first  letter  of  the  name  of  each  information  flow.  All  ICOM's  are  given  a  title 
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CONTROLS 


INPUTS 


OUTPUTS 


ACTIVITY 


MECHANISMS 


Figure  Al.  An  Example  of  a  Generic  IDEF  Activity  Model 


and  a  glossary  defining  each  ICOM  and  activity  accompanies  the  models.  IDEF  uses  four 
types  of  activity  diagrams  to  represent  the  business  process: 

•  Node  Trees  (Figure  A2)  -  A  representation  of  the  activities  without  the  associated 

ICOM's.  The  dots  on  the  tree  represent  an  activity,  while  the  lines  of  the  tree 
represent  a  decomposition  relationship  between  activities.  A  node  allows  the  re- 
engineering  team  to  see  how  the  activities  are  related  hierarchically,  and  to  get 
an  overall  view  of  the  business  process.  They  can  determine  which  activities  are 
actually  part  of  their  program  and  which  activities  are  outside  the  scope  of  their 
efforts. 
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• 


• 


Context  Diagrams  (Figure  A3)  -  A  representation  of  the  highest  level  activity  and 
its  associated  ICOM's.  The  highest  level  activity  is  the  entire  process  being 
modeled. 

Decomposition  Diagrams  (Figure  A4)  -  A  breakdown  of  the  context  diagram  into 
subactivities  and  associated  ICOM's. 

FEO  (For  Exposition  Only)  diagrams  -  Used  to  focus  in  on  a  particular  portion 
of  a  decomposition  diagram. 


The  ability  of  IDEF  to  decompose  processes  hierarchically  is  its  strongest  feature 
and  makes  it  particularly  suitable  to  re-engineering.  Users  of  the  IDEF  modeling 
techniques  can  examine  any  portion  of  the  business  process  in  great  detail  since  a  given 
process  can  be  broken  down  into  several  sub-processes.  This  feature  allows  the  re- 
engineering  team  to  view  the  complete  business  process  in  detail  and  to  identify  those 
non-value  added  activities  that  are  the  target  for  elimination  in  any  program  of  re- 
engineering.  IDEF  can  be  used  to  model  the  "AS-IS"  process  from  which  the  cost 
drivers  are  identified  and  then  to  model  the  "TO-BE"  process  with  un-needed  cost  drivers 
eliminated  and  a  more  efficient  process  defined. 
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Figure  A2.  An  Example  of  a  Node  Tree 
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Figure  A3 .  An  Example  of  a  Context  Diagram 
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Figure  A4.  An  Example  of  a  Decomposition  Diagram 


66 


Appendix  B.    Procedures  for  Activity  Based  Costing  — 
Determining  Activity  Costs  Through  IDEFO  Modeling 


ABC  recognizes  the  causal  relationships  of  cost  drivers  to  activities.  Practitioners 
of  Activity  Based  Management  (ABM)  analyze  activity  costs  and  focus  on  the 
management  of  these  activities.  The  goal  is  to  improve  the  value  received  by  the 
customer  in  terms  of  increased  profit  or  benefits  received. 
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ABC  used  in  conjunction  with  IDEFO  modeling  brings  together  the  factors 
necessary  to  aid  decision  makers  in  identifying  and  implementing  improvement 
opportunities.  ABC  consists  of  fives  phases  (Figure  Bl).  Each  phase  is  accomplished 
in  sequence  by  a  small  group  of  persons  called  the  team  to  establish  a  baseline  for 
activity  cost  performance.  Once  trained  in  the  techniques  of  breaking  down  activities 
into  cost  factors  the  team  assists  functional  users  in  gathering  costs,  defining  activity-cost 
concerns,  and  constructing  ABM  cost  databases.  Once  a  validated  cost  database  is 
established,  updating  cost  data  becomes  an  easy  task  to  be  performed  on  an  annual  basis. 

A.  Analyze  Activities 

Operating  management  decides  the  scope  of  activities,  often  numbering  in  the 
dozens,  to  be  analyzed.  The  program  should  encompass  six  to  ten  units  within  the 
organization  that  have  common  functional  areas  stemming  from  the  same  budgetary 
appropriation.  IDEFO  is  used  to  create  "AS-IS"  models  of  the  business  process.  The 
activities  identified  through  this  modeling  technique  are  those  which  form  the  foundation 
for  ABC  analysis.  These  models  are  validated  and  processes  analyzed  to  characterize 
activities  as  either  value-added  or  non- valued-added. 

B.  Gather  Costs 

At  the  same  time  activities  are  analyzed  the  Team  examines  historic  data  to  collect 
cost  information  associated  with  the  business  process.  These  costs  will  later  be  traced 
to  specific  activities  to  facilitate  the  identification  of  cost  improvement  opportunities. 
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C.  Trace  Costs  to  Activities 

This  phase  merges  the  results  of  activity  analysis  and  cost-gathering  to  produce 
an  input  cost  for  each  activity.  It  is  these  input  costs  that  are  used  as  part  of  the  output 
measure. 

D.  Establish  Output  Measures 

The  next  step  is  to  calculate  the  activity  unit  cost.  One  primary  output  must  be 
identified  for  each  activity.  The  output  must  be  quantifiable.  Activity  unit  cost  is 
determined  by  dividing  the  input  cost  by  the  output  volume. 

E.  Analyze  Costs 

Analyze  costs  uses  information  derived  from  the  previous  phases  to  determine 
improvement  opportunities.  Non- value-added  activities  are  identified  and  become 
candidates  for  modernization  or  elimination. 
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Glossary  of  Terms 


ACTIVITY  -  A  business  process,  function,  or  task  occurring  over  time  with  recognizable 
results.  Activities  are  represented  in  an  activity  model  with  identifiable  inputs,  controls,  outputs, 
and  mechanisms. 

ACTIVITY-BASED  MANAGEMENT  (ABM)  METHODOLOGY  -  A  prescribed  process  that 
puts  activity-based  costing  (ABC)  theories  into  practice.  It  includes  the  breakdown  of  an 
enterprise  into  manageable  segments  for  detailed  analysis  regarding  cost  and  performance,  aimed 
at  effective  and  consistent  organization  of  the  enterprise's  activities,  continuous  process 
improvement,  and  the  elimination  of  waste. 

ACTIVITY  MODEL  -  A  model  that  describes  the  business  activities  for  a  particular 
environment.  The  activity  model  depicts  how  activities  relate  to  one  another  and  the  use  of  the 
environment  in  a  pictorial  format  with  various  levels  of  detail. 

ACTIVITY  MODELING  TECHNIQUE  -  A  technique  that  defines  both  the  AS-IS  and  TO-BE 
environments.  This  is  a  description  from  the  external  user's  view. 

ACTIVITY  OUTPUT  -  The  product  of  an  activity.  What  internal  or  external  customers  receive 
and  what  the  organization  produces  —  e.g.,  a  paycheck,  widget,  or  some  type  of  service. 

ACTIVITY  PERFORMANCE  MEASURE  -  A  quantifiable  measure  of  the  cost  of  performing 
an  activity,  a  measure  of  time  required,  and  how  well  an  activity  was  performed. 

ALPHA  TEST  -  A  set  of  scheduled  internal  tests  to  demonstrate  the  correctness  and 
completeness  of  conceptual  logic  models,  internal  physical  database  models,  application 
development  projects,  user  documentation,  and  Standard  Operating  Procedures  (SOP's)  within 
normal  limits. 

APPLICATION  -  The  user's  interface  into  the  system,  the  window  into  the  database.  The  User 
Interface  Application  requirements  defined  in  the  conceptual  design  are  the  actual  application 
components  that  provide  service  to  end  users. 

APPLICATION  DEVELOPMENT  TEAM  -  A  group  of  functional  users  and  technical 
specialists  whose  primary  function  is  to  oversee  the  requirements  specification,  design 
development,  programming  and  implementation  of  a  information  systems  application. 
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AS-IS  MODEL  -    A  diagrammatic  illustration  of  the  business  process  as  it  currently  exists. 

BETA  TEST  -  The  Beta  Test  is  a  normal  working  environment  test.  It  is  a  user  software 
acceptance  test  of  a  new  system  or  changes  to  a  deployed  system.  The  Beta  Test  is  conducted 
in  a  field  environment  using  a  production  "live"  database  executed  on  designated  hardware. 

BUSINESS  PROCESS  -  A  group  of  logically  related  decisions  and  activities  required  to 
manage  the  resources  of  a  business.   The  linkage  of  activities  across  functional  boundaries. 

CASE  (Computer  Aided  Software  Engineering)  -  Collective  reference  to  a  family  of  software 
development  productivity  tools. 

CIVIL  WORKS  PROGRAM  -  Major  USACE  mission  area  that  includes  water  resource 
management  and  emergency  response  programs. 

COMMAND  DATA  MODEL  -  A  fully  attributed  conceptual  data  model  that  is  the  overall 
logical  structure  of  the  Corps  of  Engineers  data,  independent  of  any  software  or  storage 
constraints.  It  may  often  contain  data  structures  not  yet  implemented  in  internal/physical  data 
models. 

COST  DRIVER  -    Factors  of  an  Activity  that  lead  directly  to  expenditures  and  create  costs. 

DATA  -  Meaningful  facts  about  persons,  places,  things,  concepts,  events,  and  activities  in  a 
defined  format  and  structure  from  which  information  may  be  derived. 

DATA  ELEMENT  -  A  property  or  characteristic  of  a  real  world  object.  A  data  element  has  a 
name  and  a  definition.  Data  elements  are  used  to  distinguish  between  real  world  objects  and  to 
provide  descriptions  of  them.   Data  elements  are  named  with  singular  nouns. 

DATA  MODEL  -  A  model  that  described  real  world  objects,  their  data  elements  and 
relationships  that  comprise  the  data  that  describe  the  business  environment  and  support  the 
activity  model. 

END  USER  -  A  person  who  uses  the  information  or  data  provided  by  a  computer  system.  For 
example,  engineers,  secretaries,  and  managers  are  all  end  users. 

FOURTH  GENERATION  LANGUAGE  (4GL)  -  Programming  language  that  uses  high-level 
human-like  instructions  to  retrieve  and  format  data  for  inquiries  and  reports. 

FUNCTIONAL  USER/CUSTOMER  -  The  responsible  Corps  individual  who  oversees  and 
manages  an  Application  Development  project  or  a  STRAP. 

GAO/IMTEC  -  General  Accounting  Office  Information  Management  Technology  report. 

IDEF  (Integrated  Computer-Aided  Manufacturing  Definitions)  MODEL  -  A  semantic 
language  based  representation  of  complex  real  world  activities  and  their  interdependencies.  These 
interdependences  are  classified  as  either  inputs,  controls,  outputs,  or  mechanisms  (ICOMS). 
IDEF  models  provide  an  understanding  of  the  activities  in  the  environment  and  their  use  of 
information. 
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IMPROVEMENT  OPPORTUNITIES  -  Identified  during  the  definition  of  the  AS-IS  Model, 
they  represent  the  areas  of  importance  to  be  focused  on  during  the  To-Be  modeling  process. 

IN-PROCESS  REVIEW  (IPR)  -  A  review  by  a  team  of  functional  and  technical  delegates  to 
determine  if  the  requirements  of  a  business  area  are  being  satisfied  in  an  efficient  manner  by  the 
Application  Development  effort. 

INFORMATION  RESOURCE  MANAGEMENT  STEERING  COMMITTEE  (IRMSC)  - 

Made  up  of  the  senior  personnel  from  the  major  directorates  and  offices  in  the  Headquarters  to 
be  concerned  with  strategic  issues  (such  as  appeal  on  data  naming  issues). 

ISP  -  Information  System  Plan 

ISPI  -  Information  System  Planning  Implementation 

LIFE  CYCLE  MANAGEMENT  -  The  control  and  administration  of  an  information  system 
throughout  its  entire  existence,  from  system  development  to  replacement. 

NON- VALUE  ADDED  ACTIVITIES  -  Anything  other  than  the  minimum  amount  of  equipment, 
materials,  space,  and  employee  essential  to  achieve  corporate  objectives  and  remain  an  ongoing 
enterprise  (e.g.,  correction,  inspection,  expediting  delay,  storage,  etc.). 

PROCESS  MODEL  -  Pictorial  representation  of  logically  related  decisions  and  activities  using 
an  accepted  modeling  technique. 

PROPONENT  -  The  USACE  organization  that  is  responsible  for  the  definition  of  the  entity 
and/or  data  element. 

STOVEPIPE  SYSTEM  -  A  separately  developed  information  system  without  shared  data  and/or 
resources. 

STRAP  (Structured  Requirements  Analysis  and  Planning)  Report  -  Process  and  data 
information  requirements  of  a  business  are  analyzed  and  documented.  A  Business  Process  is 
selected  from  those  projects  slated  during  Information  Systems  Planning  Implementation  (ISPI). 
The  overall  information  requirements  are  identified  and  projects  proposed  to  implement  these 
needs. 

TO-BE  MODEL  -  Diagrammatic  illustration  of  the  incorporation  of  business  process 
Improvement  Opportunities  with  the  Command  Data  Model  concept  of  shareable  data  across 
business  processes. 

VALUE  ADDED  ACTIVITIES  -  Contribute  to  the  achievement  of  enterprise  activities  and/or 
to  product  attributes  and  service  level  paid  by  the  customer. 
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